Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


How do you do version control?

Ben T.
  • Ben T.
    Ben T.

    I use Notepad++ mainly for VBScript and I really love it, though I think my question can apply to any scripting language.  I really need to improve on my version control.  I have copies of my scripts in multiple locations and for reasons not worth explaining here there can be different versions in each of these locations.  I end up doing a diff on these files and depending on how good my memory is, I can usually figure out which file is newer. 

    So my question is how do you do version control? 

    I started looking at CVSNT but off hand that seems too complicated for what I'm doing.  If Notepad++ had some sort of plugin that would just add a comment with the date saved and a version number that may be good enough.  But I may still consider CVSNT.

    Any other thoughts or ideas?

  • Don't do it!  CVS is all-but-dead, and for good reason :)

    There are several open source version control systems that are in the range good to excellent. 

    Subversion (otherwise known as SVN) is the "new" CVS, very easy to understand and use, and TortoiseSVN is a very capable and easy to use GUI front end that attaches to explorer. There are several plugins for Notepad++ for it.

    Git is what I use for all my personal stuff.  It's one of the simplest models, but also the most powerful - if you've not done much version control before, then this can actually be an advantage (retraining an SVN user is usually much harder).  There is something of a learning curve, but resources like http://progit.org/book explain things really well.  This is one of the "modern" distributed version control systems (DVCS), meaning that there is no central repository (although one can be created).  Development is leaning this way, due to the many benefits of this way of working. Don't be fooled into thinking "if I'm working on my own, why would I need it distributed", as it actually makes working on your own much easier (no central repo to setup and manage, as in SVN).   TortoiseGit is also available, and works in a very similar way to TortoiseSVN.

    Mercurial (otherwise known as Hg) is another DVCS, and is allegedly very good.  Generally people are in a git camp or a mercurial camp - I'm in a git camp, but only because I learnt that first, and haven't seen anything in mercurial to make me want to change, only things that make me want to stay with git.

    There are others, such as bazaar, but I don't know too much about them.

    Have fun :)

  • bbluemel

    I'm in the Mercurial Camp, and one thing I can say is TortoiseHg is much further along and tightly integrated with Hg than TortoiseGit is with Git. There's http://hginit.com which gives an intro, and some SVN "retraining".

    There's also http://hg-git.github.com/ which I haven't used yet, but should try to for Dave's git repos for the reason stated above.

    One thing that I did when I was looking to implement a DVCS (over 18 months ago now) at work was I downloaded all of Tortoise* cleints, and tried all of them.  And chose based on a number of factors, including ease of getting up and running, and how easy the varying levels of expertise we have at work would "get it".
    TortoiseHg came out king from that (note I came in to that process with zero-bias, I had only previously used VSS and SVN for "light use", and this was a decision that was going to affect the way ~20 people worked), so it could have gone either way.
    I believe TortoiseHg will still come out king because
    - it's release cycle is in sync with Mercurials (and Hg is included) - with TortoiseGit you need to install MSysGit
    - the Workbench UI is fantastic, I believe can only really be rivaled for Git by Git Tower on the Mac.

    You can semi integrate TortoiseHg with Notepad++ too with using the run commands, e.g. I use:

    thg annotate "$(FULL_CURRENT_PATH)"

    to show me the history of the file I'm currently on (so I can see who edited lines etc).
    For anything else I really just have Workbench open all the time, and do other things like Push/Pull/Merge/Commit etc from there.

    With whatever you chose, like Dave said, Have fun.


  • For personal use on your own computer, DVCS may be overkill. I'm completely happy with Subversion, but it's probably not going to be developed much further in light of the popularity of hg and git.

    TortoiseHg is written in Python, right? Doesn't that make it fairly slow? TortoiseSVN is tight.

  • For personal use on your own computer, DVCS may be overkill.

    That's just not true.  It's actually easier to setup a local git repository than it is an svn repository.  The steps are very similar, you're just not using the "D" (distributed) nature of the DVCS.


    d:\> svnadmin create testrepo
    d:\> svn mkdir file:///d:/testrepo/trunk -m "trunk created"
    d:\> svn mkdir file:///d:/testrepo/branches -m "branches created"
    d:\> svn mkdir file:///d:/testrepo/tags -m "tags created"
    d:> svn checkout file:///d:/testrepo/trunk test
    d:\> cd test
    d:\test> xcopy d:\path\to\real\code\*.* . /s
    d:\test> svn add *.vbs
    d:\test> svn commit
    ... and so on


    d:\> cd \path\to\real\code
    d:\path\to\real\code> git init
    d:\path\to\real\code> git add *.vbs
    d:\path\to\real\code> git commit
    ... and so on

    I know which I'd rather do.  I think hg is pretty much the same.  Yes, you can do these steps with TortoiseXXX, which is marginally easier, but the steps you need to take are the same.

    Hg is written mostly in Python, TortoiseHg is a port of TortoiseSVN, as far as I know - although it will use the Hg Python libraries, yes. But it's not slow - it's slower than git, but git is really fast, and compared to SVN, it's still magnitudes faster.  http://www.whygitisbetterthanx.com/#git-is-fast for some relative numbers on hg/git/bazaar performance.  He does state the he tested SVN too, and you can basically multiply the bazaar numbers by a large factor to get the SVN numbers. 

    SVN is cool, but don't ever think that distributed version control has to be distributed, or complicated :)  I use git for all my personal stuff.  Distributed comes in handy for that - I can commit and branch and merge at local speeds, and at the end of the day, if I want to I can do a quick backup to remote location, which just pushes up the new changes.  With SVN, that would mean rsync'ing the repository to somewhere, or a dump and a load.



  • Anonymous

    Is there any detailed guide on how to get started? I looked at http://progit.org/book/ but I can't get it to work

  • That's just not true.

    Hey, Dave, I've been away from these forums for a while.

    The steps you show for Subversion are a little overblown. When I create a new repo, assuming I'm following the trunk/branches/tags model, I create that entire folder structure under one directory and then use

    svn import

    . That directory is, I'll admit, a temporary one, and I have to checkout the trunk into a different folder to actually start work.

    Still, the steps you show for git don't indicate how the branches and/or tags are handled. I can imagine tags not being necessary if git's tagging is handled without a copy, but how do you set up branches in git? If it requires additional steps than what you've shown, your comparison isn't exactly fair.

    There's http://hginit.com which gives an intro, and some SVN "retraining".

    Thanks for this!

  • Ok, svn import would save some steps, but as you say, you then need to check it out in a different directory in order to create the .svn metadata directories.

    Git's branching and tagging are handled differently, so there's no setup to do.  You're automatically on a branch called "master" when you set up.  "git branch some-new-branch" will create a new branch.  "git checkout -b some-new-branch" will create new branch and immediately switch to that branch.  "git tag v0.1" will create a new tag.

    I can also recommend Git Extensions as a front end (at least under windows - I've not tried it under linux/mono), that makes it very obvious what's going on and is very quick and easy to use (better than TortoiseGit, IMHO)