You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Peter Kahn <ci...@gmail.com> on 2010/05/10 16:12:49 UTC
How do I determine if svn:mergeinfo is corrupt and how would I fix
it.
I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know how
I'd make a determination and what resources are out there to help fix
problems?
Here’s the issue. My team recently moved to agile and uses feature branches
(story branches really) where different teams work on the same sources
concurrently. As the story achieves a high state of readiness the team
merges to trunk. The merges are taking days or weeks due to missing changes,
unexpected changes, and conflicts. We are talking about teams of 5-10 people
and the effort/churn seems way to high.
People use the this merge pattern
a) PULL - merge trunk-to-branch, resolve, test, commit
b) PUSH - merge branch-to-trunk, resolve, test, commit
c) Recreate branch (or usually create new story branch and drop old since
it's done)
By the end of this the branch and trunk should be in alignment.
*Problems we are seeing:*
1. changes not reported during trunk-to-branch merge show up in
subsequent branch-to-trunk
2. conflicts on svn:mergefinfo properties during merge
3. file missing, but local edit on new file added in branch and pushed to
trunk
4. incoming + local delete (file deleted on trunk and branch shows as
conflict)
(1) Should not be happening. The pull from branch to trunk should put the
two in sync for all changes already on trunk. The changes in branch-to-trunk
merge are changes that happened on the trunk. So in the first merge they
should have propagated to branch but didn’t. This points to corruption in
mergeinfo data which would “hide” trunk changes.
(2) Should not be happening. SVN should be managing the changes in the merge
tracking. This also points to corruption in the mergeinfo data
(3) Should not be happening. This is a case of a new file added on branch.
It should show up as a new file added to trunk. This also points to
corruption in the merge info data.
(4) I believe this is a SVN bug and that we can’t fix this. Still if this
were our only problem I'd be happy
We are currently on svn 1.5.x server with clients using svn 1.6.x and
svn+ssh for connecting. We plan to go up to the latest and greatest SVN
since some fixes may impact our problems.
Still, it sure looks like our mergeinfo data is wrong.
- Merges that don't report all changes
- Conflicts in merge of mergeinfo properites
Any good places for me to start looking?
FYI, I also posted this to
Stackoverflow<http://stackoverflow.com/questions/2790471/how-do-i-determing-if-svnmergeinfo-is-corrupt-and-how-would-i-fix-it>,
but thus far "move to git" has been the only response and that's not really
an option for me at present.
--
Peter Kahn
citizenkahn@gmail.com
pkahnpie1@AIM
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action
Re: How do I determine if svn:mergeinfo is corrupt and how would
I fix it.
Posted by Stein Somers <ss...@opnet.com>.
> I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
> how I'd make a determination and what resources are out there to help
> fix problems?
I'd make the determination by reading and understanding the mergeinfo
values. They are plain text after all. The resource to read is
http://www.collab.net/community/subversion/articles/merge-info.html
Personally I think you need a file-level merge module that is tailored
to the programming language used, or a well thought out protocol to have
line-based merging sort out things for you and very disciplined programmers.
--
Stein
Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.
Posted by Philip Martin <ph...@codematters.co.uk>.
Stefan Sperling <st...@elego.de> writes:
> Blindly marking all delete vs. delete conflicts resolved is wrong
> (unless you don't care about rename conflicts).
As I said, it's debatable. One could decide that since renames don't
exist they really are just copies and deletes. In that case the
deletes don't conflict.
--
Philip
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 11, 2010 at 03:53:20PM +0100, Philip Martin wrote:
> (4) This is deliberate Subversion policy as Subversion cannot
> distinguish between simple deletes and deletes that are part of a
> move. It's debatable whether this behaviour is correct, but it is
> deliberate.
This is a problem with the current implementation.
Subversion does not currently know the difference between an incoming
rename and an incoming delete.
The options were to either flag no conflicts when renames are involved,
or flag false positive delete vs. delete conflicts. We chose the latter.
> These conflicts are explicitly marked as delete-delete
> conflicts so you should be able to detect and resolve them, perhaps
> using a post-merge script.
Any delete-delete conflict could be a rename-delete, rename-rename,
or a delete-rename conflict.
It's currently up to the user to find out which of these happened.
Blindly marking all delete vs. delete conflicts resolved is wrong
(unless you don't care about rename conflicts).
Stefan
Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.
Posted by Philip Martin <ph...@codematters.co.uk>.
Peter Kahn <ci...@gmail.com> writes:
> *Problems we are seeing:*
>
> 1. changes not reported during trunk-to-branch merge show up in
> subsequent branch-to-trunk
> 2. conflicts on svn:mergefinfo properties during merge
> 3. file missing, but local edit on new file added in branch and pushed to
> trunk
> 4. incoming + local delete (file deleted on trunk and branch shows as
> conflict)
(2) There is a recent bug fix in 1.6.11 that might be relevant
http://subversion.tigris.org/issues/show_bug.cgi?id=3573
but your description isn't detailed enough to say for sure.
(4) This is deliberate Subversion policy as Subversion cannot
distinguish between simple deletes and deletes that are part of a
move. It's debatable whether this behaviour is correct, but it is
deliberate. These conflicts are explicitly marked as delete-delete
conflicts so you should be able to detect and resolve them, perhaps
using a post-merge script.
--
Philip
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
Posted by Peter Kahn <ci...@gmail.com>.
Thanks, I am not entirely sure what people were using for their push / pull
but I'm pushing a standard now.
I think we hit the following problems that made things worse:
- cherry pick merges + merges at levels below root (all are allowed, but
they can make later merges more complex)
- we assumed merge command completion meant all changes merged (didn't
double check with mergeinfo --show-revs eligible)
- possible bugs with earlier clients (1.5 or early 1.6). We have many
ubuntu and debian systems and were unware of wandisco's update site
initially. So, we missed out on the easy way to stay current. We are now
rapidly deploying 1.6.11
PUSH
svn merge --reintegrate --accept postpone URL-branch path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible >
eligible_revs.txt
repeat until nothing left that's eligable
PULL
same pattern, but minus the --reintegrate
I'll go through our merge info data to see if there's anything that looks
like a problem and its not too large after anonimizing it I'll post it for
review.
Thanks again,
On Tue, May 11, 2010 at 7:21 AM, Stefan Sperling <st...@elego.de> wrote:
> On Mon, May 10, 2010 at 12:12:49PM -0400, Peter Kahn wrote:
> > People use the this merge pattern
> >
> > a) PULL - merge trunk-to-branch, resolve, test, commit
> >
> > b) PUSH - merge branch-to-trunk, resolve, test, commit
> >
> > c) Recreate branch (or usually create new story branch and drop old since
> > it's done)
>
> PULL, PUSH, and Recreate branch could be anything.
> Can you describe the exact commands (or button clicks) you are using at
> each of these steps? Without that information it's pretty much impossible
> to tell what the root of your problem might be.
>
> Also, if you could provide your complete mergeinfo that would help:
>
> svn propget -R -v svn:mergeinfo $REPOS_URL > allmergeinfo.txt
>
> Even if it's a lot of output, post all of it.
> You can do search/replace operations on pathnames which are
> confidential if you need to.
>
> Thanks,
> Stefan
>
--
Peter Kahn
citizenkahn@gmail.com
pkahnpie1@AIM
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 10, 2010 at 12:12:49PM -0400, Peter Kahn wrote:
> People use the this merge pattern
>
> a) PULL - merge trunk-to-branch, resolve, test, commit
>
> b) PUSH - merge branch-to-trunk, resolve, test, commit
>
> c) Recreate branch (or usually create new story branch and drop old since
> it's done)
PULL, PUSH, and Recreate branch could be anything.
Can you describe the exact commands (or button clicks) you are using at
each of these steps? Without that information it's pretty much impossible
to tell what the root of your problem might be.
Also, if you could provide your complete mergeinfo that would help:
svn propget -R -v svn:mergeinfo $REPOS_URL > allmergeinfo.txt
Even if it's a lot of output, post all of it.
You can do search/replace operations on pathnames which are
confidential if you need to.
Thanks,
Stefan