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

Why does a merge require one to supply revs at cmdline?

From: Matt England <mengland_at_mengland.net>
Date: 2006-02-10 17:39:06 CET

Why does a 'svn merge' command require one to supply revs at the cmdline?

Details:

Put another way: if the svn system already knows from which rev a branch
was copied/branched (and --stop-on-copy demonstrates that it does, or at
least can know), why does the human user need to manually extract this rev
number (in addition to the *last* rev number) and supply it on command line
as per:

$ svn merge -r 341:405
http://svn.example.com/repos/calc/branches/my-calc-branch

As demonstrated at:

http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1

?

In other words, why can't svn be "smart" about this operation:

$ svn merge http://svn.example.com/repos/calc/branches/my-calc-branch

...and simply apply all the changes made in my-calc-branch so that the user
doesn't have to hunt down the rev numbers and type them in on the command
line...which if you're merging a lot, particularly with individual files,
can be a rather tedious task to do over and over. Yes, the svn system
would have to be smart enough to figure out, if the '-r' switch is not
provided, if the target represented by the parameter (in the above example)
is truly a branch/copy of the current working copy directory...but is that
really that hard?

Is this simply a future feature? I'd sure like it. I can see continually
merging to be a dreaded task, especially with all the branches I can see
forthcoming in my open-source project.

-Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 10 17:42:52 2006

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

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