Jump to content
The Dark Mod Forums

New version control options


Recommended Posts

I have noticed recently that Sourceforge have caught up a bit and added support for distributed version control systems Mercurial, Git and Bazaar alongside their traditional SVN support. It might be worth considering upgrading to one of these, since there are couple of major advantages with DVCS systems:

 

1. Much faster log and history retrieval, since the entire history is stored locally rather than on the server. Getting a diff for any arbitrary revision requires no server access and is very quick.

2. Easier and more powerful branch and merge support, since these systems operate in terms of tracking "changesets" rather than revisions. Creating experimental branches (locally, no need for server access), making changes on the branch and then pulling the changesets into the main branch or pushing them to another developer is a streamlined and efficient workflow, unlike SVN where merging is a pain in the ass.

 

Of course whether to switch is a decision that should be made by the active developers, not by me, but it is worth giving some consideration to in light of the relatively poor performance of the Sourceforge SVN service.

Link to comment
Share on other sites

Interesting. I have no experience with other version control systems, and so far I've always been happy with the features SVN offered to me - were it not for the painfully slow sourceforge SVN servers. We have our own SVN server in our company (it's out on the net) and it's amazingly fast.

 

I'll have to check it out some time, I guess. Are there converters available for migrating SVN repos into any of the other systems?

Link to comment
Share on other sites

Which one of these mentioned systems would be ranked at the top, in your opinion?

 

Although I personally like Git, it is somewhat technical in usage and doesn't offer good Windows support at the moment, so I think it would have to be one of Mercurial or Bazaar. Although my experience of these is limited, based on some research I would lean towards Mercurial I think, since it seems to be more widely used and mature.

 

There is a well-written Mercurial guide here: http://hgbook.red-bean.com/read/

 

and the Tortoise client for Windows: http://tortoisehg.bitbucket.org/

Link to comment
Share on other sites

On the downside, with f.i. distributed revision control systems like git, you loose the handy features like the globally increasing revision number, which is easily remembered and compared for and by humans (you can instantly tell that revision 1 is older than revision 5). With git, all you have a unwieldely MD5 hashes - and I can't remember 123456790asdf132448 let alone compare it to 123456790adsf132448 in my head.

 

But of course I am not a DR developer so my opinion little matters.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

On the downside, with f.i. distributed revision control systems like git, you loose the handy features like the globally increasing revision number, which is easily remembered and compared for and by humans (you can instantly tell that revision 1 is older than revision 5).

 

Right, because they are tracking changesets rather than revisions, the concept of a global revision number doesn't exist. However, other than the inability to put a revision number into the About dialog, I can't immediately think of a significant disadvantage to this -- you could still insert a build date and a parent changeset ID, which would uniquely identify the source revision.

 

With git, all you have a unwieldely MD5 hashes - and I can't remember 123456790asdf132448 let alone compare it to 123456790adsf132448 in my head.

 

Mercurial does provide local revision numbers which increase incrementally like SVN, but these are only local to your own repository (because somebody else might have pulled in changes in a different order, for instance). It is also possible in some cases to select changes by date/time rather than ID, e.g. "hg update -d 13:18".

Link to comment
Share on other sites

OK, in the interests of experimentation I have enabled Mercurial support and imported the SVN history. This does not affect the existing SVN repository and you may continue working with it as normal.

 

The Mercurial repository is at the following URL:

 

ssh://your-user-name@darkradiant.hg.sourceforge.net/hgroot/darkradiant/darkradiant

 

with the command-line tool, you would check it out with

 

hg clone ssh://your-user-name@darkradiant.hg.sourceforge.net/hgroot/darkradiant/darkradiant local-name-to-use

 

NOTE: By default, at least with the command-line client, hg does not use SSH compression. You can enable it by using hg clone -e 'ssh -C' ssh://..., or by setting it in your global ssh config file. I don't know how the Tortoise client handles compression.

 

An interesting test is to see how long it takes to clone the repository, considering it contains the entire history of every branch and tag (except for the win32deps and win64deps which I did not import yet).

 

Another thing I noticed is that updating to the head of another branch is very very quick, for example hg update scenegraph_refactor to switch to the scenegraph refactoring branch takes only a few seconds, rather than the several minutes required for SVN to download all of the changes.

Link to comment
Share on other sites

Right, because they are tracking changesets rather than revisions, the concept of a global revision number doesn't exist. However, other than the inability to put a revision number into the About dialog, I can't immediately think of a significant disadvantage to this -- you could still insert a build date and a parent changeset ID, which would uniquely identify the source revision.

 

I am not talking about the "about dialog", but more about the "the bug was introduced with revision XYZ (and we know that comes after XYZ+1 and before XYZ-1)" instead of "changeset xyabcdef782737317 introduced it and nobody can't remember that number, nor has any idea when that was or in what relation to the rest of the code" (I assume you can still know by whom the changeset was, tho)

 

 

Mercurial does provide local revision numbers which increase incrementally like SVN, but these are only local to your own repository (because somebody else might have pulled in changes in a different order, for instance).

 

I still don't know why people think this is a good idea, tho. I rather like the central control, the increasing revisions and order. With the freedom of "pull changes in any order" comes quite a chaotic element into it.

 

Edit: There are some changes which are truly independend of each other (like fix typo in file A, fix typo in file B), but a lot of code changes are really important to be in the order they were added so I still fail to see the advantage of having someone pull them in different order. But I probably still haven't groked the entire "distributed" concept or why it is so great. (In 5 years we probably all move back to the "central repository" model, anyway, then the cycle repeats :) End of edit.

 

But its your code, anyway :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I am not talking about the "about dialog", but more about the "the bug was introduced with revision XYZ (and we know that comes after XYZ+1 and before XYZ-1)" instead of "changeset xyabcdef782737317 introduced it and nobody can't remember that number, nor has any idea when that was or in what relation to the rest of the code" (I assume you can still know by whom the changeset was, tho)

 

Fortunately, the version control system can remember the changeset number, and it is trivial to find out who committed it, when, what the diff was, and all of the parent revisions leading up to it (along with their diffs).

 

I still don't know why people think this is a good idea, tho. I rather like the central control, the increasing revisions and order. With the freedom of "pull changes in any order" comes quite a chaotic element into it. Edit: There are some changes which are truly independend of each other (like fix typo in file A, fix typo in file B), but a lot of code changes are really important to be in the order they were added so I still fail to see the advantage of having someone pull them in different order.

 

Obviously a series of dependent changes have to be pulled in order, but if people can pull different changes from different repositories, there is no way to enforce a global "revision number", so MD5 or SHA hashes are the only reliable way to uniquely identify a particular changeset.

 

But I probably still haven't groked the entire "distributed" concept or why it is so great.

 

I can't summarise the benefits of distributed version control any better than Joel Spolsky in his recent article on the subject:

 

http://www.joelonsoftware.com/items/2010/03/17.html

 

Basically it is about merging (which any experienced SVN user will admit is a right pain in SVN), rather than the distributed part.

 

EDIT: Here is I think the most important point from the article:

 

When you manage changes instead of managing versions, merging works better, and therefore, you can branch any time your organizational goals require it, because merging back will be a piece of cake.

 

I can’t tell you how many Subversion users have told me the following story: “We tried to branch our code, and that worked fine. But when it came time to merge back, it was a complete nightmare and we had to practically reapply every change by hand, and we swore never again and we developed a new way of developing software using if statements instead of branches.”

 

Sometimes they’re even kind of proud of this new, single-trunk invention of theirs. As if it’s a virtue to work around the fact that your version control tool is not doing what it’s meant to do.

 

With distributed version control, merges are easy and work fine. So you can actually have a stable branch and a development branch, or create long-lived branches for your QA team where they test things before deployment, or you can create short-lived branches to try out new ideas and see how they work.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...