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

Re: Remote renames create subtree mergeinfo

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Tue, 27 Aug 2019 22:24:14 -0400

On Tue, Aug 27, 2019 at 12:42 PM <bryce.schober_at_gmail.com> wrote:

> FWIW, I found the explanations in these two emails from the same thread to
> be easier to understand as a user:
> https://svn.haxx.se/users/archive-2010-11/0408.shtml
> https://svn.haxx.se/users/archive-2010-11/0466.shtml
>
> This sounds like yet another UX flaw caused by the constraints of
> subversion's characteristic "flexibility" afforded by its nearly-complete
> agnosticism regarding repository branching and tagging structure.
>

Out of curiosity why does it matter if svn creates mergeinfo for that copy?

More below:

If subversion were to have a configurable "strict structure" mode that
> could both enforce and simplify its behavior in use-cases like this, it
> could be a big win. It could even provide simplified "tag" and "branch"
> aliases to "svn copy", as well as "--tag" and "--branch" options to switch,
> merge, etc. I suppose directions like that may have been taken before with
> svn wrapper systems, but those never catch on or survive unless they are
> upstream.
>

I would do it differently.

I'd give Subversion actual "branch" and "tag" commands, as follows:

I'd create a new property, svn:project.

In your repo you can have any number of "projects." The presence of
svn:project on a directory would tell Subversion to expect to find trunk,
branches, and tags subdirectories. If you want to call them something else,
put "trunk=foo" (newline) "branches=bar" (newline) "tags=baz" for some
values of foo, bar, and baz, in svn:property. This opens up the possibility
to add other "project settings" in the future.

Then Subversion gets two new commands, 'branch' and 'tag.' These do the
same copy behind the scenes that you're doing today but with less typing
and more smarts because they know what your intentions are. They will
refuse to copy directories that aren't a trunk or branch or tag so you
won't end up with unwanted mergeinfo somewhere. Want to insist on it? Use
ye olde 'svn cp' whose behavior does not change.

Also, merge and switch can take a simple name parameter and automatically
resolve it to the correct URL, when you have svn:project.

Checking out can be simplified: give the URL to the svn:project directory
and it will automatically checkout trunk and name the WC after the project,
unless you specify otherwise, by giving a URL to a non-svn:project
directory, or a "bypass this 'smart' business" argument.

All of this would happen only if svn:project is set on that directory. If
not, then "svn branch" and "svn tag" are not valid commands and will error
out, while "svn merge" and "svn switch" continue to work as they do today,
namely you must specify the location.
Received on 2019-08-28 04:24:36 CEST

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.