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.
> Your problem seems to be that you merge this code back into the trunk,
when
> there is no need for a merge. The code on the branch as it is after
the
> last merge from the trunk is what you want to have on the trunk -- if
you
> have done the merges from the trunk to the branch correctly. (If not,
you
> need to find these problems either way.) So a move of the code on the
> branch to the trunk should do it; there's no need for a merge.
>
> AFAIK this code move is not directly supported by cvsnt, but the
earlier
> thread Tony E mentioned showed some solutions for this close to its
end.
You are correct that if the dev branch has been re-based right up to the
HEAD that this final merge back to the trunk is effectively a direct
copy. My problem is that this functionality *used* to be supported by
CVSNT and we have been using it successfully for quite some time and
wish to continue to use it. Having to manually copy files introduces a
manual element which increases the window for possible errors.
Also, our process is of course not as strict as I have described. It
allows for the engineers professional judgement in deciding if the very
latest HEAD needs to be merged into the dev branch. If the only changes
to the trunk since the last rebase are not significant or in a
completely unrelated area, if may be worth skipping that step and
merging directly to the trunk.
With the old version of CVSNT the final merge into the trunk was
performed exactly the same in either of the two scenarios. This
simplified the process a lot and was a significant deciding factor in
the choice to use CVS.
> If you look at merging in terms of deltas between revisions and try to
> write down the delta handling for a simple case of back-and-forth
merging
> like you described (don't forget to include some manual conflict
> resolution), you see that this is non-trivial even for simple cases.
That's
> basically the reason why it's better to merge in one direction, end up
with
> the final code in the branch you are merging to, and then move this
code to
> where it belongs. Can you describe in how this would be different from
your
> current process (result-wise)?
I know I'm not as clued up on the internals of merging as the folks who
wrote CVS, but as long as you can generate the delta between any two
revisions (not necessarily two revisions that are in the same
development branch) and can apply that delta to any other revision
(allowing for the possibility of conflicts) it should all hang together.
The difficult bit is deciding the Root revision for any merge. That is
what mergepoints are for.
Using the example in my original mail:
1. Start with Trunk, Branch1 and Branch2 all at revision 1.1
2. Modify on Branch1 to create revision 1.1.2.1
3. Merge Branch1 to Trunk
Target = 1.1
Source = 1.1.2.1
Common Ancestor = 1.1
No mergepoints between Target and Common Ancestor
No mergepoints between Source and Common Ancestor
Root = Common Ancestor = 1.1
Delta is Root -> Source = 1.1 -> 1.1.2.1
Apply to Target = 1.1
Target = Root, so no conflicts will be generated.
Create revision 1.2, with mergepoint = Source = 1.1.2.1
4. Modify on Branch2 to create revision 1.1.4.1
5. Merge Trunk to Branch2
Target = 1.1.4.1
Source = 1.2
Common Ancestor = 1.1
No mergepoints between Target and Common Ancestor
Mergepoints exist between Source and Common Ancestor
1.2 has mergepoint 1.1.2.1
1.1.2.1 is not ancestor of Target, ignored
Root = Common Ancestor = 1.1
Delta is Root -> Source = 1.1 -> 1.2
Apply to Target = 1.1.4.1
Target != Source, so conflicts may be generated and will need to be
manually resolved.
Create revision 1.1.4.1, with mergepoint = Source = 1.2
6. Merge Branch2 to Trunk
Target = 1.2
Source = 1.1.4.2
Common Ancestor = 1.1
Mergepoints exist between Target and Common Ancestor
1.2 has mergepoint 1.1.2.1
1.1.2.1 is not ancestor of Source, ignored
Mergepoints exist between Source and Common Ancestor
1.1.4.2 has mergepoint 1.2
1.2 is ancestor of Target, becomes new Common Ancestor
Root = Common Ancestor = 1.2
Delta is Root -> Source = 1.2 -> 1.1.4.2
Apply to Target = 1.2
Target = Root, so no conflicts will be generated.
Create revision 1.3, with mergepoint = Source = 1.1.4.2
I realise I have probably over-trivialised it, but that seems to work
for me. This is how the old version of CVS seemed to work (based on the
results of my using it, not looking at the code). Please can you show me
the scenario which results in loss of data?
Rgds,
Andy
--
Andy Harrison - Platform Software Engineer
Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ,
UK
"No matter how bad things seem...
...nothing could be worse than being used as a towel rail." - A.A. Milne
A member of the Anite Group of companies. Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.
Anite Group plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187
Scanned for viruses by BlackSpider MailControl.