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