Subject: Distributed vs Centralised SCM? - by: joefarah

Here are my thoughts...

1. If your code is distributed across many sites/depots/servers/whatever, does that mean that your ability to do a full build is affected whenever one of them, or the network to it, is down?

2. With distributed code, how do you do a consistent backup of your entire product?

3. I like multiple site solutions, as long as there is no need to do partitioning and re-synchronization operations. This seems only feasible if the entire product exists at all sites, or at least some subset of the sites.

4. When you distribute code across sites, it's probably more important that you have an at-rest encryption capability, because it's typically under less control. So if someone gets access to the files, they still don't have the goods.

5. Centralized repository with good remote access is nice, but it doesn't cut it when you start doing things like full product delta reports (vs your local workspace), full builds, etc. unless you have high speed connectivity all the way through.

These are all real concerns that have to be addressed by an SCM tool, and indeed by an ALM tool. I don't like tools that make me administer separate multiple site solutions for each component of the ALM solution (and usually not for all of them).

In CM+ here's what we do.

1. Centralized repository
2. Multiple Site option allows replication of all transactions at all sites in real time. (So each site looks and feels like a single site centralized repository.)
3. At-rest encryption option (applied at library creation time)
4. Ability to restrict certain files (or file types, products, etc.) to specific sites.
5. Access to file controlled by user roles/permissions, not by location of the file. So change sites and you have the same data and same permissions based on your user id.
6. Apply multiple site capability across all ALM functions, not just source code.
7. Use multiple site feature to provide warm-standby disaster recovery and live, up-to-date on-line backups.
8. Allow you to disconnect a site and have full read access and limited write access to the repository. So if you needed to take it to the space station, or on a flight, or out to sea.
9. Allow automatic recovery from network outages so that if you're connected to the network on the space station and you lose connectivity in some parts of your orbit, you are automatically resynched when you regain connectivity.
10. Allow remote access both through a native interface, with intelligent caching, or through a web interface.
11. Allow near-zero administration for the multiple site solution (CM+ MultiSite).
12. Ensure that schema changes (for your meta data), and process changes are automatically propagated across sites in near real time.
13. Provide an option for automatic propagation of user interface customization (by default, this can be site specific).
14. Ensure that all inter-site traffic is encrypted.
15. Use the multiple site framework to monitor synchronization for any potential problems.

As a commercial organization, centralization is important. I don't buy the suggestion that distributing data minimizes backup times, server delays, etc. If that is the case, you're using old "BIG-IT" technology, which generally is server-centric, instead of using smart clients.

I really don't think cloud computing should apply to CM/ALM, unless its pseudo-cloud (e.g. having IBM host your repository for you).

So those are my thoughts, along with how we have integrated these thoughts into the CM+ product.

View the original article here

Subject: Distributed vs Centralised SCM? - by: baynes

I'd be interested in feedback from others on this subject, and particularly comparing and contrasting the use of distributed tools such as git and mercurial (and others) vs their more centralised brethren, be they open source (subversion) or commercial.

The requirements for developing something like Linux are certainly different to those for many commercial organisations IMO.

Some of this comes from comments on the posting I made about an upcoming BCS CMSG talk on 25 Nov in London (which directly addresses the theme):

http://www.cmcrossroads.com/forums?func=view&catid=73&id=100374#100380

Thoughts?

View the original article here

Subject: Distributed vs Centralised SCM? - by: robertc

I'd be interested in feedback from others on this subject, and particularly comparing and contrasting the use of distributed tools such as git and mercurial (and others) vs their more centralised brethren, be they open source (subversion) or commercial.

The requirements for developing something like Linux are certainly different to those for many commercial organisations IMO.

Some of this comes from comments on the posting I made about an upcoming BCS CMSG talk on 25 Nov in London (which directly addresses the theme):

http://www.cmcrossroads.com/forums?func=view&catid=73&id=100374#100380

Thoughts?

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: vinnyjames

@vinnyjames
I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...

Like this.

Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.

Oh, and here's the original press release from WANDisco.

While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.

And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.

And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".

There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?

As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.

Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.

Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)

I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).

My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.

Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: mbools

@vinnyjames
I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...

Like this.

Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.

Oh, and here's the original press release from WANDisco.

While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.

And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.

And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".

There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?

As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.

Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.

Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)

I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).

My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.

Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: vinnyjames

Presented by Dan North, Agile troublemaker, developer and originator of BDD

This is a joint event with the BCS Open Source SG.

Synopsis
Big organisations like to centralise. They like the control and management of centralised services. Distributed source code management (DSCM) systems such as git and mercurial represent a potentially disruptive shift in version control. Dan has been using DSCMs for his personal projects for a couple of years now, and recently his company - a 500 person trading firm - took the decision to embrace DSCM and begin the migration towards git from its centralised, monolithic Subversion repository.

In this talk, Dan outlines some of the differences between centralised and distributed version control systems, from a technical, social and organisational perspective, and describes some of the challenges of migrating towards and using DSCM successfully in a commercial setting.

www.bcs-cmsg.org.uk/events/2010-11-25.html

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: robertc

@vinnyjames I realise you're just promoting your product, but absolutist statements like your's are plainly wrong and do not reflect well on your organisation. You cannot know what is right for all organisations. Making these statements makes you look like a one trick pony--"The answer is Subversion MultiSite. Now, what was the question?".

The synopsis does not call Subversion 'monolithic' it say's Dan's organisation's Subversion repository was centralised and monolithic, which it may well have been. I think he's better placed to make that observation than you.

It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers". It really depends on how you manage your system.

Oh, and a company's IP is all over laptops etc. with Subversion (or don't you allow working copies on laptops?). (And I assume that you're aware of the moves to make Subversion working copies maintain local history---a little like DVCS?)

If you're going to plug your product on unrelated threads (this was an event announcement, not an advocacy piece), at least do it in a way that reflects well on you, it, and your organisation.

View the original article here

Subject: Multi branch / distributed development support - by: tekkie

Bhorsoft wrote:
We've been using SVN branching for a long time. Now we only work on release branches and never use the trunk - for us the trunk is like an appendix, it is there, but not needed. We only merge "upstream". Since we may be working on two major releases and a couple of patches for the same application, we rely on branches so we can work concurrently on different releases of the same code. We have had little problem merging from the earlier releases to the later release branches.

We've been using this system for over 5 years and have never lost or mangled a change in all that time.
I am glad that your business allows you to work in such a structured way, but really is that not every business has that luxury.

Subversion is a great tool if your branches and merges are predictable, unfortunately it can't keep up when branching/mergning becomes ad-hoc (yes I know this should be avoided but business is business).

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: robertc

Presented by Dan North, Agile troublemaker, developer and originator of BDD

This is a joint event with the BCS Open Source SG.

Synopsis
Big organisations like to centralise. They like the control and management of centralised services. Distributed source code management (DSCM) systems such as git and mercurial represent a potentially disruptive shift in version control. Dan has been using DSCMs for his personal projects for a couple of years now, and recently his company - a 500 person trading firm - took the decision to embrace DSCM and begin the migration towards git from its centralised, monolithic Subversion repository.

In this talk, Dan outlines some of the differences between centralised and distributed version control systems, from a technical, social and organisational perspective, and describes some of the challenges of migrating towards and using DSCM successfully in a commercial setting.

www.bcs-cmsg.org.uk/events/2010-11-25.html

View the original article here

Multi branch / distributed development support - by: Bhorsoft

Re:Multi branch / distributed development support 1 Day, 7 Hours ago Ah, yes.... and no.
Subversion sees the revision you create during the merge between branches as a new change (which strictly speaking it is as there's no way to know that you did not take action to resolve conflicts for example). So, although it can 'see' that change 123 has been integrated it cannot know that the merge change can be taken on faith, as it were.
This is where you might get conflicts when you 'drop' the source branches. Subversion sees, and ignores, 123 but 233 is a new change (just like the problem you have when bringing a --reintegrated branch back to life where the revision created on trunk is seen as a 'poison' revision in any subsequent integration from trunk to branch). You can always 'fix' the problem with the --record-only trick to tell Subversion to ignore some revisions during the --reintegrate. Merge with a --record only from the branch into the trunk will essentially tell Subversion that you are happy that the change is already dealt with.
Using the previous example, suppose the merge between branches resulted in revision 233 being created and I then drop the sourcebranch into the trunk (--reintegrate), I can forewarn Subversion that 233 should also be ignored in any future trunk merge using the --record-only merge technique. This should only be used if 233 was created without any incident (no additional action taken when merging between branches, otherwise I may overlook some legitimate integration issues).
No tool can reliably and automatically account for this sort of thing because during the merge between branches I may have to perform all sorts of integration actions both resolving direct conflicts and also potentially performing changes to different parts of the code base to accommodate the integrated change (123). The tool can only 'blindly' resolve the record that change 123 has been integrated with 233 (which Subversion does), it cannot understand any other actions taken in 233 and so will have to account for that in the drop to trunk. This requires a human to say 'well, actually 233 has no special actions in it, so go ahead and ignore it'. I guess a tool could look at 233 and infer that, if all the deltas in 123 and 233 are identical, then 233=123, but beyond that I think a person is needed to make a judgement call as to whether 233 can be ignored completely, ignored in part, or not ignored at all.
There are ways to minimise problems of this sort (by limiting the scope of changes, making changes as small as possible, integrating changes in parts; those that need no special actions and those that do, etc.) but that's all a bit beyond this thread or my capacity to explain in a single post
Hope that all makes sense
The administrator has disabled public write access. Re:Multi branch / distributed development support 9 Hours, 56 Minutes ago I guess the following closes this topic:
www.joelonsoftware.com/items/2010/03/17.html
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.”
And more here

hginit.com/00.html
Almost every Subversion team I’ve spoken to has told me some variation on the very same story. This story is so common I should just name it “Subversion Story #1.” The story is this: at some point, they tried to branch their code, usually so that the shipping version which they gave their customers can be branched off separately from the version that the developers are playing with. And every team has told me that when they tried this, it worked fine, until they had to merge, and then it was a nightmare. What should have been a five minute process ended up with six programmers around a single computer working for two weeks trying to manually reapply every single bug fix from the stable build back into the development build.
And almost every Subversion team told me that they vowed “never again,” and they swore off branches.
THE END
The administrator has disabled public write access. Re:Multi branch / distributed development support 2 Hours, 41 Minutes ago We've been using SVN branching for a long time. Now we only work on release branches and never use the trunk - for us the trunk is like an appendix, it is there, but not needed. We only merge "upstream". Since we may be working on two major releases and a couple of patches for the same application, we rely on branches so we can work concurrently on different releases of the same code. We have had little problem merging from the earlier releases to the later release branches.
I think two of our keys is we merge daily. This ensures developers are working on the latest code. It also keeps conflicts to a minimum.
We also have centralized our merges. Only one person does the merges on a daily basis and runs a CI build immediately after the merge. That person can resolve most merge conflicts but will call on individual developers to work out any "tricky" conflicts.
We've been using this system for over 5 years and have never lost or mangled a change in all that time.
The administrator has disabled public write access. Vision without action is a daydream. Action without vision is a nightmare.
Japanese Proverb
T. V. Loy
Configuration Manager
View the original article here

Multi branch / distributed development support - by: mbools

Ah, yes.... and no.
Subversion sees the revision you create during the merge between branches as a new change (which strictly speaking it is as there's no way to know that you did not take action to resolve conflicts for example). So, although it can 'see' that change 123 has been integrated it cannot know that the merge change can be taken on faith, as it were.
This is where you might get conflicts when you 'drop' the source branches. Subversion sees, and ignores, 123 but 233 is a new change (just like the problem you have when bringing a --reintegrated branch back to life where the revision created on trunk is seen as a 'poison' revision in any subsequent integration from trunk to branch). You can always 'fix' the problem with the --record-only trick to tell Subversion to ignore some revisions during the --reintegrate. Merge with a --record only from the branch into the trunk will essentially tell Subversion that you are happy that the change is already dealt with.
Using the previous example, suppose the merge between branches resulted in revision 233 being created and I then drop the sourcebranch into the trunk (--reintegrate), I can forewarn Subversion that 233 should also be ignored in any future trunk merge using the --record-only merge technique. This should only be used if 233 was created without any incident (no additional action taken when merging between branches, otherwise I may overlook some legitimate integration issues).
No tool can reliably and automatically account for this sort of thing because during the merge between branches I may have to perform all sorts of integration actions both resolving direct conflicts and also potentially performing changes to different parts of the code base to accommodate the integrated change (123). The tool can only 'blindly' resolve the record that change 123 has been integrated with 233 (which Subversion does), it cannot understand any other actions taken in 233 and so will have to account for that in the drop to trunk. This requires a human to say 'well, actually 233 has no special actions in it, so go ahead and ignore it'. I guess a tool could look at 233 and infer that, if all the deltas in 123 and 233 are identical, then 233=123, but beyond that I think a person is needed to make a judgement call as to whether 233 can be ignored completely, ignored in part, or not ignored at all.
There are ways to minimise problems of this sort (by limiting the scope of changes, making changes as small as possible, integrating changes in parts; those that need no special actions and those that do, etc.) but that's all a bit beyond this thread or my capacity to explain in a single post
Hope that all makes sense
View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Just so I keep my wires straight (it's not clear from the other posts on this thread), what do you mean by having problems with baseless merges?

View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Ah, perhaps you were asking whether someone from another branch could --reintegrate between 5 and 6. Well, yes, but that's not a problem.

Suppose I 'drop' the branch as follows.

cd ~someone/trunk/wc
svn update
svn merge --reintegrate ^/branches/somebranch .
svn commit

Creating revision 123. This revision 123 is the 'poison' revision that will cause all sorts of trouble if we tried to merge from trunk into branch again.

Anyhow, I can sync (at pretty much any time between the drop and the next time I want to pull trunk changes up into somebranch) with:

cd ~someone/somebranch/wc
svn update
svn merge -c 123 --record-only ^/trunk
svn commit

Note, I am specifically merging only the poison revision in order to prevent problems in future. There is nothing in revision 123 that will impact the branch (it was, after all dropped from branch in the first place). Even if someone from another branch had, in the meantime, dropped revision 124 this would in no way be a problem.

Next time I merge trunk into somebranch I will see 124 as a new trunk change (no different to seeing any other trunk change) and revision 123 will be seen as 'already merged' because of my --record-only merge earlier, hence it will not cause trouble.

Even if someone adds to the somebranch before I do the bookkeeping --record-only merge it does not matter. Just so long as the bookkeeping is done before the next merge from trunk.

If you're disorganised and allow a change on trunk between the last integration into the branch and the 'drop' then you may have an issue, but that issue will simply be remerging work, Subversion will keep track of it just fine.

Suppose trunk was at 120 when you integrated up to somebranch (bringing somebranch up to date with the head of trunk). Then someone updated the trunk, adding 122. Then you 'drop' somebranch to create 123 on trunk (it would be better to pull 122 into somebranch, rebuild, retest and then drop---but let's suppose you need to mess trunk about for some reason). There may be some merge work in trunk between 122 and 123 changes. If you then merge --record-only 123 up to somebranch the next time you integrate trunk up to branch you will need to 'remerge' revision 122. The best way to avoid this is to stop working on trunk. Use trunk as a 'release' branch and use 'support' branches for defect resolution etc. That way you keep control over your integration patterns and can avoid this sort of complexity.

Maintaining trunk in this way also makes the 'drop' simpler because you can 'merge --reintegrate' and 'resolve --accept theirs-full' (not that this should be necessary if you're merging is organised properly). Assuming you make sure the source branch is always up-to-date with respect to branch before dropping (and why would you not? If you are merging during a release you are releasing untested code, which is pretty risky stuff---unless your system is properly segmented into sub-systems/modules in which case you are releasing these CI, and the providing the merging effort is isolated to one CI you should have no issues, but this is getting too complex for a forum post and somewhat off topic, so I'll stop now).

View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Ah, perhaps you were asking whether someone from another branch could --reintegrate between 5 and 6. Well, yes, but that's not a problem.

Suppose I 'drop' the branch as follows.

cd ~someone/trunk/wc
svn update
svn merge --reintegrate ^/branches/somebranch .
svn commit

Creating revision 123. This revision 123 is the 'poison' revision that will cause all sorts of trouble if we tried to merge from trunk into branch again.

Anyhow, I can sync (at pretty much any time between the drop and the next time I want to pull trunk changes up into somebranch) with:

cd ~someone/somebranch/wc
svn update
svn merge -c 123 --record-only ^/trunk
svn commit

Note, I am specifically merging only the poison revision in order to prevent problems in future. There is nothing in revision 123 that will impact the branch (it was, after all dropped from branch in the first place). Even if someone from another branch had, in the meantime, dropped revision 124 this would in no way be a problem.

Next time I merge trunk into somebranch I will see 124 as a new trunk change (no different to seeing any other trunk change) and revision 123 will be seen as 'already merged' because of my --record-only merge earlier, hence it will not cause trouble.

Even if someone adds to the somebranch before I do the bookkeeping --record-only merge it does not matter. Just so long as the bookkeeping is done before the next merge from trunk.

If you're disorganised and allow a change on trunk between the last integration into the branch and the 'drop' then you may have an issue, but that issue will simply be remerging work, Subversion will keep track of it just fine.

Suppose trunk was at 120 when you integrated up to somebranch (bringing somebranch up to date with the head of trunk). Then someone updated the trunk, adding 122. Then you 'drop' somebranch to create 123 on trunk (it would be better to pull 122 into somebranch, rebuild, retest and then drop---but let's suppose you need to mess trunk about for some reason). There may be some merge work in trunk between 122 and 123 changes. If you then merge --record-only 123 up to somebranch the next time you integrate trunk up to branch you will need to 'remerge' revision 122. The best way to avoid this is to stop working on trunk. Use trunk as a 'release' branch and use 'support' branches for defect resolution etc. That way you keep control over your integration patterns and can avoid this sort of complexity.

Maintaining trunk in this way also makes the 'drop' simpler because you can 'merge --reintegrate' and 'resolve --accept theirs-full' (not that this should be necessary if you're merging is organised properly). Assuming you make sure the source branch is always up-to-date with respect to branch before dropping (and why would you not? If you are merging during a release you are releasing untested code, which is pretty risky stuff---unless your system is properly segmented into sub-systems/modules in which case you are releasing these CI, and the providing the merging effort is isolated to one CI you should have no issues, but this is getting too complex for a forum post and somewhat off topic, so I'll stop now).

View the original article here