I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.
We use Mercurial for our source control for C# and Progress code.
We are now developing in Microsoft's Dynamic NAV. There is no built-in source control and it's awkward (and error-prone) to manually put code in/out of our Mercurial repository for versioning.
I was wondering if anyone has developed an homegrown, integrated source control system for NAV using Mercurial. What were the steps and what advice/ideas can you share?
You could put together some scripts to automatically export and import from C/SIDE to TXT files, combined with "hg add" / "hg update".
If you're on NAV 2013, then you can export by running finsql.exe with the ExportObjects command. I don't think this works directly on earlier versions, but you can probably do something similar with the EXPORTOBJECTS function in app code. There is corresponding functionality for importing.
This post on Waldo's blog might also be interesting. He also has many other posts which are relevant, as he is from the team behind Revision, an integration between NAV and TFS.
We are currently using Subversion for our version control software, and we have a license for TFS because we have MSDN.
I'm wondering if there is any tool that integrates TFS bug tracking with Subversion source control.
Thanks.
Integrate is an odd choice here, what do you wish to integrate? A work item can have any reference you like in it as it is just text.
TFS also supports customisation of work item fields so you could add fields for your SVN needs.
If you mean integrate the version control from SVN into TFS, then the TFS Integration Platform can help you with that.
No.
Using TFS only makes sense when using all of its parts, it's quite hostile against integrating other components.
If you need bugtracking and want to stick to SVN, you better use a free alternative like e.g. Bugzilla.
Thomas
I've recently taken on a project with no version control. I don't have any experience with version control myself. I feel it is the only way to go with this project (and probably any future projects now I think of it - I always trust myself too much..)
My question is - where do I begin with implementing version control on a project already in production? Bearing in mind I haven't used version control before so really it's two separate questions:
Starting out with version control
Implementing it on an already live
project
For background, the project is a php/mysql driven website using bits of javascript, I'm working on a (Windows) XAMPP server and I'm very keen to learn this new world of version control!
Congratulations, you are headed in the right direction!
You'll first need to choose a version control system. My current favorite is Git. Unfortunately, I don't think that Git is an easy introduction to version control. I have also used Subversion and Perforce.
Subversion (http://subversion.tigris.org/) works on many platforms, is used in a lot of projects, and has some nice GUI tools available (such as TortoiseSVN on Windows). Command-line tools are also available. It's also free. You can run it in "local filesystem" mode, meaning that you don't need to set up a separate server. It's come a long way from it's "better than CVS" roots.
Perforce (http://www.perforce.com/) is pretty nice. Its Windows implementation seems the best (last I checked, their cross-platform GUI was pretty lousy). You primarily use a GUI to interact with it, though again there are command-line tools. It's commercial software, but open source projects can get free licenses by contacting the company. The biggest drag is that you will need to set up a server. To get started, you could run the server on the same box that you develop on, but that's probably a bad idea in the long run. I found Perforce to be very good for 2-8 person teams; I don't know how well it would work with more.
The big advantage to Git (http://git-scm.com/) is that it requires virtually no set-up. Once installed, you can execute git init in any directory to create a new git repository. The revision history is kept inside the project's directory. You can start out with just local versioning, and you can scale up from there. If Git seems scary, you could also check out Mercurial (https://www.mercurial-scm.org/). I haven't used it, but I understand that it shares some of the same underlying principles as Git.
Avoid CVS. It's on its way out, and no new project should be using it unless they need to do so.
Adding source control to an existing project is easy. The hard part would be making sure that everybody is willing to use source control. If you're working alone, then it's just personal discipline. If you're part of a team, though, and some people have reservations, you will have problems. Try to get everybody on board, and be available to try to answer their questions. If people don't know how to use a tool, they simply won't use it.
Start here: http://svnbook.red-bean.com/
I've found SVN to be the easiest version control system to use, especially for beginners. It's pretty simple to start, the only real decision you have to make is where to host your stuff. There are a couple free svn servers available, but if you're really serious about your work you should host your own.
The first thing to do is to pick a version control paradigm (centralized versus distributed). To answer that, you'll need to take a look at your team and how you intend to handle check-in, check-out, merging, and branching. Once you pick a paradigm, you can choose a version control system. The mainstream systems are Subversion for centralized version control and Git and Mercurial for distributed version control.
If the project is live and working, then that should be your initial check-in to whatever version control you are using. You need a reliable baseline that you can revert to and have 0 work to deploy something that works. If your project is not functional...well, good luck. You might want to check in to start using version control and then decide how you want to proceed (either get the project to a stable and functioning state and then restart your repository or have your initial check-in be a broken system).
If the rest of the team doesn't see the benefit with version control, I would recommend installing your own system on your machine and, at the very least, use it for your own work.
Be prepared for some resistance from management and/or your co-workers. Management may not want to invest the resources for a repository machine -- these things need to be installed, maintained, backed-up, etc. Or they may object to you spending time on an "extra" like a RCS.
Your co-workers, especially if they're unfamiliar with any RCS, are likely to resist using it, or complain that it's too hard to use. There's a learning curve to any new tool, and source control systems are no exception. It's worth the time to learn, though.
My advice is to pick one -- any one that strikes your fancy -- and start using it. Don't worry about getting it 100% perfect the 1st time, it probably won't be any worse than what you have now, which is one misplaced keystroke away from oblivion.
Play with it. Check files out into a separate workspace and hack things up, knowing that it doesn't matter; you can always revert it. Learn how to use your new tool with some GUI frontends (I'm fond of 'svn diff --diff-cmd=kdiff3', myself). Get to the point where you know how to check in & out, tags things, branch, and merge. Then show your co-workers.
Personally, I'm fond of svn, but I didn't choose it; it chose me.
Step 1: Download Mercurial.
Step 2: In your favorite command line, go to the root of your source directory and type hg init.
Step 3: Do a make clean or equivalent (ie. all you want is source, no generated files).
Step 4: Type hg addremove.
Step 5: Type hg commit.
From this point on you can:
Examine the changes between your most recent commit and now: hg diff or hg status.
Make checkpoints in your code: hg commit.
Return to previous checkpoints: hg update -C -r 0
Congratulations, you are now using version control: It's really not that hard, and it's very, very useful (if for no other reason than you can look at the changes you've made to see if they make sense).
At some point you'll probably want to learn about branching (if only so that you have a backup copy of your repository on another machine) at which point you can turn to the documentation or the book.
I don't know if there is something similar for php etc, but an interesting resource here is "Brownfield Application Development in .NET". In many ways, this only uses .NET for the examples; most of the book is really about tackling policies exactly like you mention:
how to introduce source control
how to introduce unit testing
how to introduce continuous integration
etc
and all the concerns/consideration that go with them.
Partly relating to the code; but also relating to the "human" factor; colleagues, managers, etc. I highly recommend it; but you might decide the .NET background is inappropriate for you (it is a good fit for me ;-p).
You can look here: git-for-beginners-the-definitive-practical-guide
This one is a distributed version control system that currently has a good windows support with Git on Windows and a shell extension with TortoiseGit
An addition to other answers:
If the project you want to put under version control have had some releases, and if those versions are available for example as tarfiles (e.g. project-0.1.tar.gz, project-0.2.tar.gz, project-0.3.tar.gz, ...) you might want to consider importing those versions into your chosen version control system. Git for example has import-tars.perl and import-zips.py in contrib/fast-import/ directory, and writing support for other files in other programming languages for git fast-import should be easy.
Sidenote: my preferred version control system is Git.
See also: Good link or book for basics and theory of version control question.
I learned the concepts from the pragmatic series:
example for subversion, they also have books on GIT as well.
I only have experience with SourceSafe and SVN.
SourceSafe seems to have issues with corrupting it's own database, on a team of 5 we were repairing the db probably once a month. It's easy, but still something you shouldn't have to deal with. It's difficult to label code too and use that label for anything practical.
SVN is nice, it's simple to install on Linux or Windows. Most IDEs have a plugin for it, and if you're using Windows there is an Explorer extension (TortoiseSVN) that allows you to do all your operations right from Windows Explorer. There's a lot of SVN tools out there for every OS, it's very well supported. SVN also integrates with TRAC (a bug tracking system), and Bugzilla so you can tie your work tickets to code.
I will say that [HOW you use version control is probably just as, if not more important than which package you use][2]. Using it simply as a library is a very rudimentary application of it, but for a 1-2 man team making a website or an app where you won't be maintaining builds and versions, you'll be ok.
When it comes to version control, anything is better than nothing.
Wow, everyone is just boosting his favorite version control utility.
OK, to answer your question, how do you put a project under version control?
It's not that hard, once you pick a version control utility (be it, git, svn, hg, bzr .. whatever) there's usually a command or two to initialize a repository then add all the relevant files to it.
For instance, in git it might be something like:
$git init
$git add --all
$git commit -m"First commit"
Now, about choosing a version control utility, that's a tough question and highly depends on what you want. You might want to have a look at this question:
Popularity of Git/Mercurial/Bazaar vs. which to recommend
The only tools you should consider choosing among are:
git
svn (Subversion)
hg (Merculiar)
bzr (Bazaar)
mtn (Monotone)
Everything else is either old or commercial.
svn follows a server-client model; there's a central repository. If you're a one-man team then the only thing this means to you is that you have to setup a server and make sure it starts with the computer. Though I heard that you can do away with the server. A bit of googling turns up this guide for using svn without a server
All other tools follow a distributed model, again, if you're a one-man team, the only thing this means to you is that there's no server to setup.
The advantage of svn is that it's been there for a while and has many gui front-ends and better IDE integration.
I can't compare git to hg (merculiar) since I haven't used the latter, but git has a unique storage model compared to svn and hg.
bzr is said to be easier to use, but slower (it's written in python).
I'm personally satisfied with git, but you should do your own research; or maybe just choose one and stick with it. As far as I can tell, they're all mature and stable.