Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Fri, 12 Jan 2007 10:26:37 +0000, Arthur Barrett wrote:
> Andreas,
>
> >> and also allowed changes to be lost.
> >
> > Which as far as I see is still an unsubstantiated claim.
>
> How many times do I have to tell people to read the thread?
I was there.
> >From Tony Hoyle's e-mail Dateed: Mon, 05 Jun 2006 14:45:39 +0100
> >
> > It's very easy.
> >
Create file 1.1
> > Branch
Tag on 1.1.0.2
> > Make changes in B
Yielding 1.1.2.1
To make it not-quite-trivial, I also changed the head to 1.2.
If I don't the Merge A->B does not yield anything to commit
(since there wasn't any change on the head (resp. A) since
the branch).
> > Merge A->B
RCS file: /opt/cvs/null/ak/test.txt,v
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into test.txt
Merge base versions are as expected, and the
file contents as well -> 1.1.2.2
> > Merge B->A
RCS file: /opt/cvs/null/ak/test.txt,v
retrieving revision 1.2
retrieving revision 1.1.2.2
Merging differences between 1.2 and 1.1.2.2 into test.txt
Again, the proper merge bases have been selected, and
the resulting file is as expected (containing modifications
from head and branch) -> 1.3.
Actually 1.3 and 1.1.2.2 are identical, which you expect
after merging both ways with no intervening changes.
> > If you use the merge point the changes in the second step are lost.
Nope. Worked like a charm.
> Note: I haven't tested this - but the only reason why this was "fixed" is
> that it could lead to loss, and Tony was doing the testing at that time.
I suspect Tony was burned by some mistakes in manual conflict resolution.
...
> >> As always - if you want some feature in CVSNT that isn't there - you can
> >> add it.
> >
> > At http://s17.ath.cx/tmp/cvsmergep.txt there is a patch. Use at own risk.
>
> The correct place for patches is the dev list - please re-post there.
Basically, the 'patch' is already in the repository, around
cvsnt/src/update.c revision 1.44.2.126.
...
> > Instead of making cvs able to support prcesses that
> > other-vcs-with-merge-arrows do easily.
> >
>
> The only other tool that has been mentioned on this list capable of this is
> ClearCase. Last time I checked this costs US$5000 per seat with no access
> to the source code and no free version and only works on a high-speed
> network (the "multi site" version costs more). Are you proposing that March
> Hare use these same economics to add this one feature?
Nope. I see that full multi-branch merge support requires nontrivial
computation of the stuff needed to merge, and it can't always been done
in a single diff3 run. Frankly, I don't know *how* clearcase handles
these cases, so I'm not in a position to request this. It will
probably require some nontrivial redesign of 'cvs update' and its
user interaction.
On the other hand, bidirectional merges between two branches are always
trivial (except in case of crossing merges), they already were in the
code base once, and they are still bragged about in the wiki ("When
I merge back and forth from dev branch to HEAD, it is a very simple
operation--I just specify the branch to merge from, and cvsnt takes care
of the rest. -- http://www.cvsnt.org/wiki/MergePoint). Note the 'back
and forth'.
> I've already demonstrated that people are using this "feature request" as a
> poor solution to a process implementation issue.
Aka 'the error is with you, not with us, even with us removing that
very feature that draw you to cvsnt in the first place'.
...
> processes, but we will only get there if people continue to contribute (as
> you have with your patch, and others do by purchasing support or adding
> documentation).
As you are convinced that the feature back-and-forth-merge is broken
*by design* there is no real need to supply a patch. I hope to get
the design misconception out of your heads some day.
Andreas
--
np: 4'33