Brian,
Thanks for the reply.
You nailed it. This is exactly the situation we are having.
I have been manually removing those mergeinfo props as I was educating
myself on how they work.
We do merge at the root.
It seems that the issues started appearing when people started adding
files in the original branch that were not in the destination branch.
To make matters worse, I think some engineers have been merging at the
subfolder level every now and then.
We have updated our best practices to avoid those.
I am still learning about SVN from the admin side... do you know if by
chance I could create a "hook" to remove the mergeinfo prop for any
file below the root (~/Branches/Branch123)?
Thanks,
Eric.
On Jul 19, 8:36 am, Brian Gideon <briangid..._at_yahoo.com> wrote:
> On Jul 18, 12:30 pm, Eric Liprandi <eric.lipra..._at_gmail.com> wrote:
>
>
>
>
>
> > Hi,
>
> > Not sure this is a bug.
> > I might not understand the whole merge tracking changes that came out
> > with 1.5.
>
> > Anyway...
> > We have 2 branches (A and B).
> > On the local machine, we update both branches to HEAD (though only 1
> > matters, the target).
> > We initiate the merge from A to B, for a single revision X.
> > On the surface, it works great.
> > The changes for revision X are correctly applied to Branch B.
> > But all the sudden, we also have a slew of files that are marked as
> > modified.
> > Those modified files only have their property "snv:mergeinfo" changed.
> > Committing all the pending changes has somehow random results.
> > Committing only the files we know had change in revision X works
> > always fine.
>
> > Any pointers as to what is happening? are we misusing the tool?
>
> > Regards,
>
> > Eric.
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> > For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
>
> Okay, what's probably happening is Subversion is adding the
> svn:mergeinfo property to files it shouldn't be. There is a known
> issue that is being worked on that will correct this. It's not really
> a bug, but more of a suboptimal implementation. If you rename or move
> a directory or file Subversion will either copy the svn:mergeinfo
> contents from the node's nearest parent containing that property and
> place it on that node or it will create an empty svn:mergeinfo
> property. In most cases this shouldn't be necessary because that
> property can be inherited from a node's parent. It's not going to
> cause any problems with the merge tracking, but will cause the
> repository to grow faster than necessary. I have been running into
> this a lot since I do a lot of refactoring that requires me to rename
> and move files around on different branches. It also causes confusing
> results in the log messages and prevents you from doing a reintegrate
> branch merge.
>
> What I have been doing to work around the issue is to manually delete
> all of the unnecessary svn:mergeinfo properties. This is actually
> easier than it sounds. Assuming that you always branch from the root
> (trunk) of your code you should only have the property on the root
> folder so what you can do is to create the property on all children of
> that folder (which hopefully will be a small number) and then remove
> recursively. That will wipe out the property on everything except the
> root. It's a quick procedure, but you have to remember to do it
> before you commit changes.
>
> See the following article for more information about the problem.
>
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org- Hide quoted text -
>
> - Show quoted text -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-19 18:08:33 CEST