1.5 merge tracking expectations

[Blair Zajac <bl...@orcaware.com>]

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.

I'd hate for people to move to 1.5, do a bunch of work in trunk, and then find 
out they can't merge that to a branch, for whatever reason or limitations we have.

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?

Having a very explicit section saying, if you do these commits in the source URL 
and try to merge to a destination URL, you will run into issues will be very 
helpful.  The known limitations section currently just lists an issue with 
merging back to trunk with the --reintegrate flag.

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?

Blair


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 1.5 merge tracking expectations

[Stefan Sperling <st...@elego.de>]

On Wed, Jun 11, 2008 at 10:03:44AM -0700, Blair Zajac wrote:
> 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.
> 
> I'd hate for people to move to 1.5, do a bunch of work in trunk, and then find 
> out they can't merge that to a branch, for whatever reason or limitations we have.
> 
> 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?

+1

To chip in an example:

I would still recommend manually replaying on the target branch
any moves that happened on the source branch, before doing a merge.

Seriously.

Stefan

Re: 1.5 merge tracking expectations

[Karl Fogel <kf...@red-bean.com>]

Blair Zajac <bl...@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
work-in-progress.

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?

Yup.

> 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?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org