On Friday 29 April 2011, you wrote:
> I have a repository in which I frequently merge changes from a release
> branch back to the trunk (when fixing bugs, for example, that need to be
> put in the trunk). However, whenever I do this, I always get several
> files and folders that want to be merged, regardless of the fact that they
> have been merged dozens of times in the past.
Actually, I don't know what you are talking about here. I guess the thing you
are talking about is mentioned later:
> users wonder why these files/folders keep appearing in the commit logs!
i.e. that files/folders which are not touched by the merge keep coming up in
the commit dialog as changed.
Firstly, you can configure which headers are shown in the commit dialog's list
of files. There, you should display the text status and property status. You
will probably find that the text status of the mysterious files is always
"unchanged" but their property status is "changed". Also, when committing,
those files will not be in the list of files who's content is transmitted,
because there is no content change to transmit.
> I suspect it has something to do with mergeinfo, but I am totally
> unfamiliar with mergeinfo (and properties in general) and have never
> really needed to deal with them anyway.
Yes, I guess so too. The idea about mergeinfo is that it records the already
merged revisions, so they can be skipped in future merges. Now, the mechanics
of this property are that if a file/dir has no svn:merginfo property, those of
the parent dir apply.
Typically, this looks like this:
trunk/ mergeinfo=branch 1,2,3
trunk/A
trunk/B
As you see, only the root has mergeinfo. Now, you made a change to A in the
branch and merge that change back to A in the trunk. The result is this:
trunk/ mergeinfo=branch 1,2,3
trunk/A mergeinfo=branch 1,2,3,4
trunk/B
Nothing unexpected so far. Now, you make another change to the branch,
affecting B, but this time you don't merge branch/B to trunk/B but instead
merge branch to trunk. These are the results:
trunk/ mergeinfo=branch 1,2,3,5
trunk/A mergeinfo=branch 1,2,3,4,5
trunk/B
Even though A was untouched, it had its mergeinfo updated, which is probably
what you are seeing. The root cause for this was that the first merge was from
a subdir to a subdir, so now the mergeinfo of the subdir is maintained
separately from that of the root dir.
HINT: Always merge the project's root only!
> How can I clean up my repository so that these files/folders don't keep
> wanting to be merged all the time?
If you merged revision 4 to the root dir, it would get added there. Since it
already is in root/A, nothing would be changed there. Since the mergeinfo of
trunk is now also the same as that of trunk/A, the separate mergeinfo of
trunk/A will be removed. Comparing and consolidating the merges can be quite
an effort though.
In some cases, it is actually intentional that only part of a change is
merged, like the changes made to A but not those made to B. In that case, I
would say you made a mistake, because you committed two changes that can be
separated in one commit, which makes it impossible to merge them separately.
If you know you don't need the changes to B in trunk, you can go and mark the
revision as changed without applying the changes.
Another way is to simply go and delete the mergeinfo property from trunk/A.
Yes, this can confuse SVN because it would consider the removed revisions for
merging again, even though the changes are already in the file. This is not a
big problem though, since selecting the revisions to merge is typically done
by a clueful human with a purpose. Further, most revisions were hopefully
merged to the root anyway.
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2730014
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-04 11:07:40 CEST