Remote renames create subtree mergeinfo

[Bryce Schober <br...@gmail.com>]

I just noticed that whenever we do a remote rename (from URI to URI, as opposed to in a working copy), svn add mergeinfo that didn't exist before. It doesn't do this for renames in a working copy. Is this by design, or by accident?

Re: Remote renames create subtree mergeinfo

[Nathan Hartman <ha...@gmail.com>]

On Tue, Aug 27, 2019 at 10:24 PM Nathan Hartman <ha...@gmail.com>
wrote:

> 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.
>

I don't know why my stupid MUA made it look like some of what I wrote was
quoted to someone else but I wrote the above paragraph.

Re: Remote renames create subtree mergeinfo

[Nathan Hartman <ha...@gmail.com>]

On Tue, Aug 27, 2019 at 12:42 PM <br...@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.

Re: Remote renames create subtree mergeinfo

[br...@gmail.com]

I disagree: I still use svn because of its centralized nature and good
native out-of-the-box handling of large binary files. Git will never really
check those boxes.

On Tue, Aug 27, 2019, 4:02 PM Nico Kadel-Garcia <nk...@gmail.com> wrote:

> On Tue, Aug 27, 2019 at 12:42 PM <br...@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. As I use
> git more and more for all of my daily development, I continue to run into
> UX problems like this that are made so much less helpful and more
> surprising, all in the name of that ultimate "everything is just a
> sub-tree" flexibility. I am coming to strongly believe that this design
> paradigm is SVN's fatal flaw keeping it from being the best long-term
> centralized VCS competitor to git & other DVCSes.
>
> You are a decade late for that discussion. Enforcing  other system's
> architecture on top of Subversion would break the very reasons people
> still use it.
>

Re: Remote renames create subtree mergeinfo

[Nico Kadel-Garcia <nk...@gmail.com>]

On Tue, Aug 27, 2019 at 12:42 PM <br...@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. As I use git more and more for all of my daily development, I continue to run into UX problems like this that are made so much less helpful and more surprising, all in the name of that ultimate "everything is just a sub-tree" flexibility. I am coming to strongly believe that this design paradigm is SVN's fatal flaw keeping it from being the best long-term centralized VCS competitor to git & other DVCSes.

You are a decade late for that discussion. Enforcing  other system's
architecture on top of Subversion would break the very reasons people
still use it.

Re: Remote renames create subtree mergeinfo

[Stefan Sperling <st...@elego.de>]

On Tue, Aug 27, 2019 at 09:41:37AM -0700, bryce.schober@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. As I use
> git more and more for all of my daily development, I continue to run into
> UX problems like this that are made so much less helpful and more
> surprising, all in the name of that ultimate "everything is just a
> sub-tree" flexibility. I am coming to strongly believe that this design
> paradigm is SVN's fatal flaw keeping it from being the best long-term
> centralized VCS competitor to git & other DVCSes.
> 
> 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.

Many such ideas have been proposed and discussed over the past years.

What has always been getting in the way of making such changes now are SVN"s
strong backwards-compatibility promises. These have been of great advantage
to both the project and its users, but the flip side is that making invasive
changes is getting increasingly hard as more features get added over time.

If the people involved in designing merge-tracking for SVN 1.5 had known
what we know today, things would likely look very different. Mergeinfo
would ideally be stored as pure meta-data and remain mostly invisible to
the user. Tree conflict detection should have been built in from day one.
But all that is water under the bridge at this point.

Furthermore, today, the project lacks sufficient developer resources to
make very large changes in the first place. We will keep maintaining the
code for years to come, but large new features are unlikely to be developed
unless the development community grows again.

Cheers,
Stefan

Re: Remote renames create subtree mergeinfo

[Daniel Shahaf <d....@daniel.shahaf.name>]

bryce.schober@gmail.com wrote on Tue, Aug 27, 2019 at 09:41:37 -0700:
> 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.

Quoting those emails (thanks for the links):

> [the change] allows for the following rules of thumb:
> 
> - If you do a copy within a working copy of your branch, Subversion assumes
>   that you want to copy something within your branch.
> - If you do a URL-URL copy, Subversion assumes that you want to create a
>   new branch. 

> The short story, the following behaviors are intentional:
> 
> A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo
> if the source has it.
> 
> B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit
> mergeinfo if the source has it. If the source doesn't have explicit
> mergeinfo, but inherits it, then that inherited mergeinfo is made
> explicit on the destination. 

The surface problem here, as I see it, is this: the behaviour of 'svn cp
foo bar' depends not only on what PATH@REV coordinate each argument denotes.

I would have expected the following to be an invariant:
.
    "«svn ${subcommand} ./foo@BASE» is equivalent to «svn ${subcommand}
    $(svn info --show-item=url ./foo)@${svn info --show-item=revision foo}»." 
.
or perhaps this:
.
    "If «foo» and «bar» denote the same tree entry, then «svn
    ${subcommand} foo» and «svn ${subcommand} bar» are equivalent."

Either of these invariants implies that whether the arguments are
specified by URL or by local path should make no difference to the
result.

"In the face of ambiguity, refuse the temptation to guess."

Cheers,

Daniel

Re: Remote renames create subtree mergeinfo

[br...@gmail.com]

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. As I use
git more and more for all of my daily development, I continue to run into
UX problems like this that are made so much less helpful and more
surprising, all in the name of that ultimate "everything is just a
sub-tree" flexibility. I am coming to strongly believe that this design
paradigm is SVN's fatal flaw keeping it from being the best long-term
centralized VCS competitor to git & other DVCSes.

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.

<><  <><  <><
Bryce Schober


On Tue, Aug 27, 2019 at 2:43 AM Johan Corveleyn <jc...@gmail.com> wrote:

> On Wed, Aug 21, 2019 at 6:55 PM Bryce Schober <br...@gmail.com>
> wrote:
> >
> > I just noticed that whenever we do a remote rename (from URI to URI, as
> opposed to in a working copy), svn add mergeinfo that didn't exist before.
> It doesn't do this for renames in a working copy. Is this by design, or by
> accident?
>
> This is by design. See amongst others these mail threads:
>
> https://svn.haxx.se/users/archive-2010-11/0357.shtml
> https://svn.haxx.se/users/archive-2017-11/0017.shtml
>
> --
> Johan
>

Re: Remote renames create subtree mergeinfo

[Johan Corveleyn <jc...@gmail.com>]

On Wed, Aug 21, 2019 at 6:55 PM Bryce Schober <br...@gmail.com> wrote:
>
> I just noticed that whenever we do a remote rename (from URI to URI, as opposed to in a working copy), svn add mergeinfo that didn't exist before. It doesn't do this for renames in a working copy. Is this by design, or by accident?

This is by design. See amongst others these mail threads:

https://svn.haxx.se/users/archive-2010-11/0357.shtml
https://svn.haxx.se/users/archive-2017-11/0017.shtml

-- 
Johan