[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Branch Merging Behaviour
From: |
Mark Cooper |
Subject: |
Re: Branch Merging Behaviour |
Date: |
Thu, 20 Mar 2003 15:07:20 +0000 |
Thanks for that Matthew.
I've tried this with all versions of cvs (running as a :pserver: on linux
and AIX) from 1.11.1.2 to 1.11.1.5, with clients under windows and linux
from 1.11.1.1 onwards, with the same result in every combination. The
truth of the matter is that even if the latest taken branch consists of
the same revisions of code as the head, merging the earlier branch into
the later branch will re-add the files, but merging the earlier branch
into the head directly doesn't.
Anyway, I'll do as you suggest as soon as I have time and post the results
to the list.
Thanks again
Mark Cooper
Reuse Manager
Microlise Limited
http://www.microlise.co.uk
mailto:address@hidden
"Matthew Herrmann" <address@hidden>
Sent by: address@hidden
19/03/2003 22:50
To: <address@hidden>
cc:
Subject: Re: Branch Merging Behaviour
Hi Mark,
A merge doesn't care where it is from a branch to a branch, or a branch to
a
trunk... it is just applying a set of diffs to files.
To troubleshoot, it's best to think in terms of an individual file, not a
whole module.
In the case of removing a file that was on the branch, you should have:
file1.c 1.1 state: alive tag: BRANCHHEAD
file1.c 1.1.2.1 state: dead tag: BRANCH
then when you merge this changes between BRANCHHEAD and BRANCH, then this
becomes the change between revision 1.1 and 1.1.2.1 on file1.c, that is,
the
state changing to "dead".
What should happen is that whenever, in any working directory, on any
branch:
- file1.c has state "alive" (i think they call it "exp")
- calling the function "cvs up -j1.1 -j1.1.2.1 file1.c" causes "cvs rm -f
file1.c" to be invoked on the working directory.
If this doesn't happen, then you have a clear bug.
There has been lots of confusion (and I think bugs also ) with relation to
handling of the Attic directory in CVS, which handles files which do not
exist on the trunk. This would be the first place to look.
If you do a search for removing files and "attic", you will probably pick
up
a whole spate of people's previous problems.
To solve the problem, I recommend you:
- try out a simple example with exactly one file on a local repository,
adding and removing it from branches, etc. and then email the list with a
transcript of your instructions, and the output of the "cvs log" function.
- report your cvs client and server versions. bugs such as the one you
mention tend to be picked up from time to time and fixed. I have a very
recent version which fixed a bug I found in branch-of-branch handling when
giving log output. This means there is a good chance your bug is fixed on
a
new version.
HTH,
Matthew Herrmann
--------------------------------------
Far Edge Technology
http://www.faredge.com.au/
-----Original Message-----
Date: Wed, 19 Mar 2003 17:11:40 +0000
From: "Mark Cooper" <address@hidden>
To: address@hidden
Subject: Re: Branch Merging Behaviour
...
We have recently noticed a difference in the way that a merge works
between two branches and between a branch and the main trunk.
Consider the following:
branch taken from trunk
work proceeds
some files removed from trunk (head)
new branch taken from trunk
working copy updated to new branch
first branch merged into new branch
What appears to be happening under this scenario is that the files that
were removed from the trunk but which still exist in the early branch are
re-added into the new branch, then when in its turn the new branch is
merged back into the trunk, the files are re-added to the trunk. This has
caused us a couple of headaches wondering why removed files kept
mysteriously re-appearing on the trunk.
This does not occur when doing a merge of a branch into a working copy of
the the trunk (head revisions).
Is this behaviour correct?
I've searched through previous mailing list archives and issue/bug
reports, but can't find any reference to this. The manual is particularly
obscure about the subject.
Mark Cooper
Reuse Manager
Microlise Limited
http://www.microlise.co.uk
mailto:address@hidden
_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs
------------------------------
_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs
End of Info-cvs Digest, Vol 4, Issue 34
***************************************
_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs