RFC: how should the svn client handle merges?

[Mo DeJong <md...@cygnus.com>]

Hi all.

I wonder if I could elicit some comments about
how merging from a branch or merging a set
of changes should be done in subversion.

The cvs client will merge changes made
on a branch into the WC using a -j argument.

% cvs update -j branch

This is not currently implemented in
the svn client.

% svn update -j branch
svn: invalid option character: j


The cvs client also supports some other
forms of -j merging:

Merge a range of changes:

% cvs update -j fromtag -j totag

Merge a range of individual file revs:

% cvs update -j 1.3 -j 1.5 file.c

You can also checkout again using -j:

% cvs checkout -j branch module


Now before anyone goes off to hack -j
support into these subcommands, I think
we should examine our options.

I contend that a merge from another branch
is not the same conceptual operation as
updating with respect to the current branch.
Passing a -j flag to the update command does
not just modify some optional feature of an
update, it goes off and does a completely
different operation. For this reason, I
propose that merging be done with a separate
subcommand.

Instead of:

% cvs update -j branch-11

One could use:

% svn merge branch-11


This has some nice benefits. The update and
checkout commands are easier to implement.
More important is the fact that they would
be easier to document. This -j stuff is
not that hard, once you get use to it.
It is the getting used to it that is hard,
we want to help people avoid this pain.

The fact that svn records what revs have
been merged into a local tree will really
help since it removes the most common
reason for a two -j merge. Users will
would able to simply run:

% svn merge branch

over and over again to get changes made
on the branch. CVS has a nasty way
of generating all sorts of conflicts
when you do this twice. The only way
to avoid it is to use two -j flags.


There is a downside to the approach I
suggest. When two tags are passed to
the merge subcommand, we might have
some trouble deciding if the second
argument is a tag or a file name.

% svn merge tag1 tag2 file5 file6

In this case, it tag2 a tag or a filename?
I don't think we would want to test to
see if "tag2" was a file, but that is
one possible solution.

One might also envision a syntax to
indicate a range of tags with a
delimiter to separate items in a range:

% svn merge tag1:tag2

% snv merge "tag1 tag2"

If none of these sounds reasonable, the -r
argument could always be used with the
merge subcommand.

% snv merge -r tag1 -r tag2 file1 file2

So, what do folks think? Is a -j merge
a fundamentally different operation than
an update? Does a merge subcommand provide
a better conceptual mapping when compared
to an overloaded update or checkout command?
Would it be easier to use and remember?
Adding a merge subcommand does not add
a feature that is not available in the
current cvs client, it simply provides
a different (and easier) way to access
the same functionality.

cheers
Mo DeJong
Red Hat Inc

Re: RFC: how should the svn client handle merges?

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

The user interface for branches is a Pandora's box that we've avoided
discussion on.

Remember that like perforce, subversion "tags" and "branches"  are
normal subdirectories in the repository... they look like regular
filesystem subdirs.

Do we present these subdirs directly to the user?  Or do we "hide"
them somehow in the repos filesystem, and svn clients present branches
in a cvs-ey way?

We're planning to talk about this next month. :)

Mo DeJong <md...@cygnus.com> writes:

> Hi all.
> 
> I wonder if I could elicit some comments about
> how merging from a branch or merging a set
> of changes should be done in subversion.
> 
> The cvs client will merge changes made
> on a branch into the WC using a -j argument.
> 
> % cvs update -j branch
> 
> This is not currently implemented in
> the svn client.
> 
> % svn update -j branch
> svn: invalid option character: j
> 
> 
> The cvs client also supports some other
> forms of -j merging:
> 
> Merge a range of changes:
> 
> % cvs update -j fromtag -j totag
> 
> Merge a range of individual file revs:
> 
> % cvs update -j 1.3 -j 1.5 file.c
> 
> You can also checkout again using -j:
> 
> % cvs checkout -j branch module
> 
> 
> Now before anyone goes off to hack -j
> support into these subcommands, I think
> we should examine our options.
> 
> I contend that a merge from another branch
> is not the same conceptual operation as
> updating with respect to the current branch.
> Passing a -j flag to the update command does
> not just modify some optional feature of an
> update, it goes off and does a completely
> different operation. For this reason, I
> propose that merging be done with a separate
> subcommand.
> 
> Instead of:
> 
> % cvs update -j branch-11
> 
> One could use:
> 
> % svn merge branch-11
> 
> 
> This has some nice benefits. The update and
> checkout commands are easier to implement.
> More important is the fact that they would
> be easier to document. This -j stuff is
> not that hard, once you get use to it.
> It is the getting used to it that is hard,
> we want to help people avoid this pain.
> 
> The fact that svn records what revs have
> been merged into a local tree will really
> help since it removes the most common
> reason for a two -j merge. Users will
> would able to simply run:
> 
> % svn merge branch
> 
> over and over again to get changes made
> on the branch. CVS has a nasty way
> of generating all sorts of conflicts
> when you do this twice. The only way
> to avoid it is to use two -j flags.
> 
> 
> There is a downside to the approach I
> suggest. When two tags are passed to
> the merge subcommand, we might have
> some trouble deciding if the second
> argument is a tag or a file name.
> 
> % svn merge tag1 tag2 file5 file6
> 
> In this case, it tag2 a tag or a filename?
> I don't think we would want to test to
> see if "tag2" was a file, but that is
> one possible solution.
> 
> One might also envision a syntax to
> indicate a range of tags with a
> delimiter to separate items in a range:
> 
> % svn merge tag1:tag2
> 
> % snv merge "tag1 tag2"
> 
> If none of these sounds reasonable, the -r
> argument could always be used with the
> merge subcommand.
> 
> % snv merge -r tag1 -r tag2 file1 file2
> 
> So, what do folks think? Is a -j merge
> a fundamentally different operation than
> an update? Does a merge subcommand provide
> a better conceptual mapping when compared
> to an overloaded update or checkout command?
> Would it be easier to use and remember?
> Adding a merge subcommand does not add
> a feature that is not available in the
> current cvs client, it simply provides
> a different (and easier) way to access
> the same functionality.
> 
> cheers
> Mo DeJong
> Red Hat Inc