RE: RFC: Standardizing a 'svn:branch' (boolean) property

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: maandag 16 juli 2012 19:08
> To: dev_at_subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On 16.07.2012 14:11, Bert Huijben wrote:
> > Hi,
> >
> > On the Berlin hackathon the suggestion was raised that it might help that
> we
> > standardize a new 'svn:branch' property to give tooling a hint on what
> > directories are branches and which aren't. To make sure we don't forget
> > about this idea I just drop this on the list with the information I have. I
> > hope others can extend this proposal with their own ideas.
> >
> >
> > Client tools like TortoiseSVN, Subclipse, AnkhSVN could really use some
> > standardized hint to suggest better defaults to the user.
>
> This idea looks to me very much like a solution looking for a problem.
>
> First of all: which problem, specifically, are you trying to solve? And
> how can this problem not be solved today by inspecting svn:mergeinfo?

A simple question this 'might' help answer is:

I have a project file ^/trunk/src/Ankh.Package/Ankh.Package.csproj, which my user wants to check out. Which directory level should we suggest the user checks out?
If we guess wrong the user can't build or use this project.

Yes, I can show a text box with no text and make the user type a url, but that is not user friendly. Usually svn:root would be on ^/trunk so the initial selection would be ^/trunk.
(Currently we guess based on directory names and subversion client specific properties)

This example is easy but with ^/Products/MyProduct/branches/final/src/libraries/mylib/lib.csproj things get harder and a svn:branch would really help.

I have no idea how I would use svn:mergeinfo to get this same information.

And other cases are: which locations in the UI should we show the merge functions for (and for which ones should we show them only in the advanced command section)

In AnkhSVN we live in an IDE and if every addin would always show all its commands all the time the average menu size would be three screens high.

>
> Regardless of what we tell users, there are a few things that we have to
> understand about Subversion's data model before we proceed with any
> discussion of branch-foo-like features:
>
> * Directories are not branches. /Copies/ of nodes (not only
> directories) represent branch points, and the difference is significant.
> * Subversion does not have named branches. Paths are only incidentally
> useful for hinting at branch identity, but are far from definitive,
> as Julian will happily tell you at some length. :)
> * Even if, for the sake of argument, we assume that directory names
> can be used equivalently to branch names, you still have to take
> into account that the /contents/ of a directory can have a
> completely different branch history than the directory itself.

I'm not saying directories aren't branches. I'm just suggesting that we give tools a hint to what directories are used as branches.

And I'm not alone in this wish. Subclipse and at least one other client already have their own marking system. (I think they standardized that property well before or around when we introduced merge tracking in Subversion). With the inherited properties work we will also finally have a standard api to just retrieve the information with one mostly fixed-time operation.

I'm certainly not advocating forbidding operations on all other levels. Instead I want to make it easier for users to do the right thing and to make their lives easier when they prefer to use GUIs.

A lot of my users start experimenting with the branch command and start creating branches at 'unexpected' locations in the repository. Some even try to create branches in other repositories, which of course doesn't work as they expect. Giving some sane defaults would help them understand how things work in Subversion.

        Bert

> Incidentally, the above points are the reason why a mapping from
> Subversion's current data model to one where branches are top-level,
> first-class objects in a separate namespace is very hard and may prove
> to be impossible. The idea of an svn:branch property seems to assume
> that such a mapping is possible; but I would like to see something more
> rigorous than "client tools could really use some hint" before believing
> that such a property would solve any case that cannot be solved by
> information available to clients today.
>
> -- Brane
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Received on 2012-07-16 19:52:40 CEST