[cvsnt] Re: Branch merging - this seems wrong...

[Prochazka, Jan]

Hello All,

I want to support Tony's concern regarding bi-directional merging. We do
the same with the same purpose:

- Crating branch for an arbitrary feature development
- merging from HEAD from time to time to be on-track with other changes
- merging the branch back to HEAD
- the unwanted side effect is that plenty of files with zero changes
(all of them ?) are committed to the HEAD.
- It is quite painful as finding out what files were really changed in
the branch  is much more difficult then it would have been if CVS would
commit files with real changes only.

Jan P.



> -----Original Message-----
> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Tony Eva
> Sent: Monday, June 05, 2006 11:13
> To: cvsnt at cvsnt.org
> Subject: RE: [cvsnt] Re: Branch merging - this seems wrong...
> 
> Tony Hoyle wrote:
> > But you have not said that b1 contains HEAD - in fact they 
> may be very 
> > different.
> 
> When I gave the command 'cvs -j HEAD c.c' to merge HEAD to 
> b1, I said to CVS that b1 will now contain HEAD.  That's what 
> a merge is, surely - the incorporation of the information 
> from one branch into another.  Indeed, that's what 
> mergepoints are for: explicitly to recognise the fact that 
> once a merge has taken place, that merge must not be repeated 
> because the information has now been included in the merge recipient.
> 
> > It doesn't - it needs to take into account all changes in B that 
> > happened *before* the merge too.
> 
> The result of the merge is a file (on B) that has all of B's 
> changes up to the merge, and all of A's changes from the 
> branch point up to the merge.  Assuming no other changes on A 
> or B, a merge from B->A is just a copy because all of the 
> information from A and B are in the head of B.  There is no 
> other information that isn't there.
> 
> > If you [do] bidirectional merges you don't have a proper changeset 
> > since you haven't clearly separated the changes.
> 
> Maybe 'changeset' was the wrong term, and maybe also we're 
> running into confliciting views about how we anticipate that 
> CVS would be used.  This is how I see it:
> 
> If a developer is responsible for implementing a feature of 
> some complexity, the coding/testing may take some time.  It 
> would be reasonable for them to want to save their 
> intermediate work into the repository from time to time, to 
> guard against accidental loss of their working copy; so they 
> would wish to perform occasional commits of unstable (or even 
> non-functional) code.  They cannot commit this to a stable 
> HEAD, and so will instead create a private branch and commit 
> to that.  Since the feature takes some time to code and test, 
> HEAD will move on, and they will wish to keep their private 
> branch up to date with regular merges from it.  Finally, they 
> will make the last couple of changes, do a final merge from 
> HEAD to pick up the last few updates, run their last test, 
> and then commit for the last time to their private branch.
> 
> Now the feature is complete and stable, it can be included 
> into HEAD.  That's where the "bidirectional" merge comes in 
> (and, in my view, comes unstuck).
> 
> > Normally this wouldn't be handled by branches at all - you'd do it 
> > using the builtin support using bug IDs or by either cooperative or 
> > reserved edits.
> 
> I may well be trying to use branches for something other than 
> their intended purpose, and maybe bugids will do what I want.
> I will look into that in more detail.
> 
> However CVS *does* support the ability to put individual 
> files on a branch, not the whole repository, and it is a 
> legitimate use of the branching capability (IMHO) to allow a 
> set of files to be collected together as I outlined.
> 
> I still believe that the CVSNT behaviour under the 
> bi-directional merge scenario is counter-intuitive, and I 
> struggle to see how it can be regarded as correct.
> 
> Sorry if I'm banging on about this too much, and I appreciate 
> the responses so far - I am just having some difficulty 
> working out if it's possible to use CVS to support the 
> development model I need.  If not, so be it, though I can't 
> see that what I'm proposing is particularly weird, so I feel 
> there must be a way of doing it.
> 
> --
> Tony
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> 
> _____________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> 

_____________________________________________________________________
This email message, including any attachments, may contain confidential and proprietary information for the sole use of the intended recipient.  If you are not the intended recipient, you are hereby notified that any use, copying or dissemination of this message is strictly prohibited.  If you received this message in error, please notify Brooks Automation, Inc. immediately by reply email or by calling Brooks US Headquarters at +1 978-262-2400. Then delete this message from your system, without making any copy or distribution.  Thank you.