On 01/26/2011 09:52 AM, Ulrich Eckhardt wrote:
>> Working with svn project for longer time causes growth of mergeinfo
>> property and very unreadable diffs between commits.
>
> There is one good rule about merging, and that is to always merge to the same
> root directory of the project. Once parts of a project are merged separately,
> they retain their own svn:mergeinfo property, and every merge to the root
> then changes these, too, even if nothing on that child item was changed. This
> of course requires that you don't mix different changes in a single commit,
> but that is a best practice anyway.
Merging always to the same directory that is what i am trying to do.
Unfortunately it doesn't work every time. I agree that project could be
leaded wrong but (and again, unfortunately) i had to work with it and
handle problems like this one :)
>> SVN with every commit updates mergeinfo value what is needed to keep
>> tracking merges, but sometimes updating this value is no longer needed
>> because merged branch no longer exists and i do not need to remember
>> about it.
>> I created a program that checks every mergeinfo property and if listed
>> path doesn't exists it is removed.
>> What do you think about this solution? Do you think it is safe?
>
> You could nuke the whole svn:mergeinfo without SVN itself falling apart.
> However, some things won't work "right" automatically any more. In particular
> SVN won't ignore requests to merge things that were already merged, because
> it doesn't know about them. Now, the chance of someone merging from a deleted
> branch (which is of course still possible!) are small, so I guess your method
> is safe.
I guess it's safe. Some tests made today brought much fewer mergeinfo
entries and merges with existing branches are still possible.
Naturally i'm losing some tracking information, but as you notice chance
to need it are small. And in fact, if i really wanted to go back to
state before cleaning action i could edit mergeinfo properties manually.
greetings
--
Piotr Kabacinski
a2Fib3Q=--------
Received on 2011-01-26 20:58:01 CET