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
Received on Sat Oct 21 14:36:26 2006