Dear users,
I am working in a team of approximately 20 developers, we are using server version 1.6.13 and Tortoise client 1.6.11.
We have noticed several problems, but are not sure whether the problems are in:
1. server part,
2. client part, or
3. our usage of both of them.
Basically, they have all something to do with merges and/or mergeinfo.
I am sorry if sometimes I cannot provide more detailed information about the steps to reproduce these problems.
1. Problem 1 - merging range influences merging results
It is logical that merging range does NOT influence merging results.
Meaning, I should get the same results when merging 100 revisions at once or 10 times 10 revisions.
But we have noticed it is not so - in all cases the problem was somehow related with a deletion of file/directory.
Usually the difference is only seen in mergeinfo.
But once we even had very strange case where two branches were created and the same range was merged from TRUNK (but in different steps).
We ended up with 2 exact branches (content and mergeinfo) - at least according to Tortoise repo-browser comparison.
But one branch could be re-integrated into TRUNK, and the other one could NOT.
Are their any known limitations when choosing merging ranges?
Our current rule is: when choosing merging range, the revision which deletes at least one file/folder must be first in the range.
Does this make sense?
2. Problem 2 - order of actions influences mergeinfo
I have a very simple example.
I have TRUNK and two branches (X and Y) created from TRUNK.
Now the work is finished in both branches and I want to re-integrate them back to TRUNK.
But in the meantime, one file/folder in branch Y has mergeinfo (although it has no mergeinfo in TRUNK).
If I first merge branch X and then branch Y, the same file/folder in TRUNK will get mergeinfo - the one as in branch Y (except for TRUNK entries, of course), plus the final information about the merge of branch Y.
But if I first merge branch Y and then branch X, the mergeinfo will also contain information about merge of branch X.
I understand why this happens, but I don't understand why such behaviour is wanted.
I mean, what exactly do I get with this information when it is obvious that in branch X this particular mergeinfo was not added/changed?
3. Problem 3 - how should "only mark as merged" option work?
Again, a small example: there is branch X, then branch Y created from it, and branch Z created from branch Y.
At first, all 3 branches have exactly the same content and no mergeinfo.
Now, I perform either test 1 or test 2, getting 2 different results.
- Test 1:
revision 10: change file A in branch X
revision 11: merge revision 10 (branch X) to branch Y -> this changes file A and adds mergeinfo for X:10
revision 12: merge revision 11 (branch Y) to branch Z -> this changes file A and adds mergeinfo for X:10 and Y:11
revision 13: re-integrate branch Z to branch Y -> no content is changed, mergeinfo is added for Z:12
- Test 2:
revision 10: change file A in branch X
revision 11: merge revision 10 (branch X) to branch Y -> this changes file A and adds mergeinfo for X:10
revision 12: accidentally perform the same change of file A in branch Z
revision 13: now that it is clear that this is the same change as in Y:11, only mark as merged Y:11 -> no content is changed, mergeinfo is added for Y:11 (but not for X:10)
revision 14: re-integrate branch Z to branch Y -> no content is changed, mergeinfo is added for Z:12-13, but also removed for X:10
In both tests the content is exactly the same.
But in second test mergeinfo for X:10 is missing - meaning branch X was not merged to branch Y.
Is this behaviour wanted?
Why is it like that?
What if we want also to keep mergeinfo changes when marking a revision as merged?
Should we then also mark those other changes as merged?
In other words - is this a bug in Subversion or it is exactly how it should work and instead we should use it a bit differently to achieve what we expect?
4. Problem 4 - corrupt and obsolete mergeinfo
Well, this is the most important question of all.
In our project we have reached approximately revision 28000.
In the beginning of our project we didn't know exactly how we should use merges and we made some bad actions.
We have also removed some mergeinfos or manipulated it manually.
Also lately we made some suspicious merges and corrections of mergeinfo.
Our mergeinfo contains information since the beginning in revision 1.
Let's say that we need mergeinfo for last 6 months of work and everything that is older than that can be considered obsolete.
Is it possible that we somehow remove some obsolete information?
Is such action dangerous?
If we are allowed to do that, what are the limitations or rules when doing that?
I suppose we should do such action in TRUNK first, am I right?
I also suppose we should only remove mergeinfo about old dead branches, not the ones that are still active and being merged to.
In advance, thanks a lot for your answers.
I hope you can help me and my colleagues.
Best regards,
Igor Radic
Received on 2010-11-11 22:38:56 CET