RE: RFC: Standardizing a 'svn:branch' (boolean) property
From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 16 Jul 2012 19:51:59 +0200
> -----Original Message-----
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?
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.
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.
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.
> Incidentally, the above points are the reason why a mapping from
This is an archived mail posted to the Subversion Dev mailing list.