• (cs) in reply to gilhad
    gilhad:
    In DVCS it just needed one address to configuration and that was all for the setup. I do not know, how to manage that simply in centralized VCS.

    Thanks to a completely in-house version of that state flow, with multiple people in each of the first, second, and third positions, I managed to get the chance to do that, using RCS. Admittedly, RCS isn't a centralized VCS, but we migrated to CVS while I was working on that, so it kinda counts. And then first joined up again, along with fourth that they'd hooked up with during the separation.

    OMG, it's a pain. It wasn't that difficult to write a script to take a particular branch of one RCS/CVS file, and upload it to another RCS/CVS file at a particular point. However, determining the appropriate point to attach things is not particularly trivial also - especially when there's some collaboration between the groups while they're split.

    In some cases, that resulted in one of the later versions being identical - because one group handed a file to the other group, and the other group just took it. In that case, it'd be appropriate to split the tree one is importing at that point, attaching the rest of the tree there, rather than continuing to import into basically the same structure as the original file.

    In other cases, that merely resulted in a massive change in one group's tree in a single checkin, that caused it to almost, but not quite, sync with another version in the other group's tree. Ideally, this would be handled as above, but it becomes much more difficult to detect.

    Eventually, though, I found the way to do it "simply".

    1. Choose which VCS instance gets to keep its head, at least for the moment. This is now the target VCS.
    2. Run a process that looks through all of the other VCSs to merge, and all of the stray foo.c.bak1234 type files you have, and sorts them in date order.
    3. Starting with the oldest version, programmatically compare it to every version in the target VCS. Commit it as a branch off of the version it most resembles. Using RCS, and preserving date stamps, this required a bit of trickery to get it to accept this, in some instances. But the code was easier to work out than going through thousands of different files and figuring out who had the oldest archive, since each group had originated some script or another and then shared it with the others.

    It doesn't sound that simple, but the point was, it was all logic I could get the computer to do for me, so the task that was looming at me looking like it'd take years went away over the course of a weekend. I'm sure there's stuff that could be optimized - you could, for example, store the length of every version, and not bother comparing any two versions where the difference in lengths between versions was greater than the minimum difference found so far. But that doesn't matter; the task is done and I'm not doing it again.

    Then, of course, we had the task of figuring out, so what changes did we then want to merge into the main branch... I don't know that any version control system could make that easy.

  • Always42 (unregistered)

    I think the discussion around version control has stagnated, at least for DVCS users.

    In the beginning the two sides were as follows:

    The traditional/centralised group. Initially, before they grew weary their naive questions/objections revolved around these old bogies:

    "Why?" "Isn't that complicated?" "The whole repository?" "No control?" "But which one is the true version?" ... etc

    And the newly converted distributed zealots (of which I was one): "How can you not?" "The work-flow flexibility will change your life." "Fully functional off-line capability." "The merging is awesome." "Easy/free context switching." "It is so easy to share." ... etc.

    Nowadays we have the same two groups but the conversation has changed.

    On the centralised/traditional side, or those purporting to be agnostic to sound more credible, folks are on the defensive. Their articles and view point can be summarise as follows: Human beings live in 4 'physical' dimensions with different people writing code (for the same application) in spurts through time. This then leads them to obnoxiously try and point out how important it is to have a plan to manage/approach this effectively... ah, duh? Where they go wrong is in trying to push the theory, based on the above, that what tool you use makes no never mind to you as a developer.

    The distributed folks are now board and have moved on with life. There is an undeniable difference in the experience of authoring code using a distributed VCS that you have to experience to grasp, not as part of a tutorial but as part of real life development.

    Come and join us, if your project forces you to use SVN/CVS/TFS, there is git-svn and co' (with similar tools for the other DVCS's). Or you can join an open source project using Git, there is nothing stopping you.

  • RV (unregistered) in reply to Abso

    FYI - We used VSS for years. If you have multiple checkouts turned on, allowing the situation you describe, then VSS will do conflict merging on the second check in. It even has a built in visual merge tool that, if configured as such, will automatically pop up to allow you fix the conflicts before commit. The only drawback is that it is not an atomic commit - so some non-conflicting files may get committed before the conflict is detected and the commit aborted. That's a significant drawback IMO.

Leave a comment on “Source Control Done Right”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article