[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.5 merge tracking expectations

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 18 Jun 2008 18:45:32 -0400

Blair Zajac <blair_at_orcaware.com> writes:
> For our 1.5.0 release notes, we should have a section that lists all
> the types of merge operations we expect or know will fail, so people
> have the proper expectations, and can choose to remain on 1.4 or
> upgrade to 1.5 and continue to use say svnmerge.py.

Somewhat late for me to be attempting to do this, but: I completely
agree. Setting expectations is very important, and merge-tracking is a

If people can follow up in this thread with scenarios they know will
fail, issue numbers that might be relevant, or anything else that comes
to mind, I'll format it and put it into svn_1.5_releasenotes.html.

Just to be clear: I'm editing that page to set expectations either way,
but the more information I have, the better I can do :-).

> For people that do a lot of refactoring and renaming, it looks like
> 1.5 will have issues, given what we saw with the issue-3000 merge?


> Say we release 1.5.0 without some of these issues resolved and fix
> them in 1.5.1. If somebody does upgrade to 1.5.0, continues to use
> svnmerge.py to avoid some of the 1.5.0 issues, then updates to 1.5.1
> and finally migrates svnmerge.py to mergeinfo using
> svnmerge-migrate-history.py, what will happen? Will the migration
> work given that the commits with 1.5.0 generated mergeinfo already?

I wish I knew the answer to that, or had time to experiment, but these
experiments take a long time and the release is fast upon us. Anyone
know the answers?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-19 00:45:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.