Home/ Questions/Q 6776171
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T15:59:44+00:00

We use SVN where I work. Most work is done on trunk, but some

  • 0

We use SVN where I work. Most work is done on trunk, but some people choose to pull branches to work on large, disruptive features. We have a convention whereby we announce that trunk is locked when we are merging a branch back to trunk. The point of this is to prevent direct trunk commits while the merge is ongoing, which necessitates another merge up prior to committing the merge back down to trunk.

Needless to say, people overlook the announcement & check stuff in anyway. (Or perhaps they are just jerks. Whatever.) We have talked about using a DVCS, which presumably would address this problem (it seems intrinsic to the concept of “distributed”), but lacking experience with them, I can’t really see how.

Using Mercurial as my poison of choice, to merge I would first pull from the central repo and do the merge locally. If someone pushes changes to central before my merge is done, my push should still fail because it will create a remote head, correct? So again I have to pull, merge, build, and in that time someone else may have pushed additional changes to central. How is this better than the situation with SVN?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The benefits mercurial would have are threefold.

    1. You can push an additional head to the central repository if you really want to (but probably it’s a bad idea). Subversion doesn’t have the concept of “heads” so you can’t do that.

    2. You can do iterative merge+commit. So, you’d pull the latest head from the “trunk” repository. You’d merge in your change. You’d commit that locally. Then, you’d pull any additional changes from the trunk, and merge them as a new changeset on top of your previous merge changeset. With subversion you can’t do that – you have to keep on trying to get the merge done in 1 hit.

    3. The merging tools are smarter (as dahlbyk has said) so these sorts of merges are generally easier to do.

    But it’s still not going to be perfect – complex merges are hard, not (generally) because the VCS is lacking, but because you need to apply your brain to work out how to take the right pieces from each person (or group)’s work. That’s hard to automate, so it’s slow and sometimes painful work.

    Better development processes and communication can help, but if you have multiple groups doing relatively independent work on the same files then you’ve got to deal with merging somewhere.

    • 0