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.
> From: Tony Hoyle [mailto:tmh at nodomain.org]
>
> >So, the current state of file.c is
> >Main_Dev: rev 1.2 (deleted)
> >Branch1: rev 1.1
> >Branch2: Doesn't exist
> >
> >Now, if I merge Branch1 -> Branch2 then file.c gets
> recreated in Branch2. Is
> >this correct?
>
> Since Branch2 doesn't exist then the Branch1 file is created -
> actually it's more like a merge from file+nothing=file.
>
> This is one of those cases where you have to keep an eye on what
> you're merging. It's not actually a mergepoint thing (mergepoints
> aren't used on deleted files) just an artefact of the merging process.
> It's debatable whether to produce a conflict in this case. A lot of
> the time the merge is new file -> branch (all branches have an
> implicit 'deleted file' if the file hasn't been added yet), and
> there's no way to distinguish between the cases. IIRC The old CVS
> used to conflict in this case but that gets annoying really fast if
> you're frequently merging - at least in our development adding files
> is much more frequent than deleting them.
Hmm, "keeping an eye on what your merging" is a bit of a problem. I'm trying
to convince my manager that we should migrate to CVS from VSS using the
argument that it does all the branching & merging automatically.
I agree that it's not a mergepoint thing, it's a common ancestor thing. If
the file was just modified, not deleted, then it would work fine. The
revision in Branch2 would be 1.2 and so the common ancestor would be 1.1.
When you merge Branch1 it would merge the differences between 1.1 and 1.1
(hence nothing) into Branch2.
Is there a difference between and implicit and an explicit deleted file?
When a file is deleted CVS creates an explicit deleted file on that branch,
with it's own revision number. When a new branch is created (from the branch
with the explicit deleted file) after the file is deleted, then that branch
only has an implicit deleted file. Is that the way it works?
I'm guessing the problem comes from the difference between an implicit and
explicit deleted file. It looks like CVS has a problem detecting the
ancestor of an implicit deleted file. If this is a problem then would it be
possible to create an explicit deleted file in the new branch? Actually it
wouldn't be a new revision it would just mean that the branch tag would be
included in the current explicit deleted file. This should mean that CVS can
then correctly detect the common ancestor. I would think this is possible as
in the scenario I described, the newly created revision is shown as
branching off this deleted revision in the WinCVS graph, so the connection
must have been made at some point.
Ok, I've just read that through again and I think some pictures might help.
Revision numbers in () indicate explicitly deleted revisions.
What it looks like before the Branch1->Branch2 merge:
[MAIN] [Branch2]
| |
1.1--[Branch1] (implicitly deleted file)
|
(1.2)
What it looks like after the Branch1->Branch2 merge:
[MAIN]
|
1.1--[Branch1]
|
(1.2)--[Branch2]
|
1.2.1.1
What I think it should look like before the Branch1->Branch2 merge:
[MAIN]
|
1.1--[Branch1]
|
(1.2)--[Branch2]
What I think it should look like after the Branch1->Branch2 merge:
[MAIN]
|
1.1--[Branch1]
|
(1.2)--[Branch2]
So, by making the association between rev 1.2 and Branch2, the common
ancestor is more easily detected. It seems that this association is already
done at some point during the merge, so it might be possible to do it a
merge time, but before the common ancestor is looked for.
This is a pretty steep learning curve for me, so please be patient if I've
made some glaring mistakes. Unfortunately I've not been able to spend
quality time with the source code so I don't have the first clue about how
this all works!
Regards,
Andy
--
Andy Harrison - Platform Software Engineer
Anite Telecoms Ltd. 127 Fleet Road, Fleet, Hampshire, GU51 3QN, UK
"No matter how bad things seem...
...nothing could be worse than being used as a towel rail." - A.A. Milne
Please note that my email domain has changed from @anitetelecoms.com to
@anite.com
Registered in England No. 1721900 Registered Office: 353 Buckingham Avenue,
Slough, Berkshire SL1 4PF, United Kingdom
Scanned for viruses by MessageLabs. The integrity and security of this message cannot be guaranteed. This email is intended for the named recipient only, and may contain confidential information and proprietary material. Any unauthorised use or disclosure is prohibited.