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.
* Merge and branch tools can automatically suggest which directory to merge
* Policy tools could use this to enforce policies with less
configuration/local rules. (Tags created must have the property; inside a
tag only certain kinds of changes are allowed)
* I don't think we can/should enforce a default policy in Subversion as that
breaks backword compatibility.
As we couldn't think of a usage of the content I would suggest that we just
always set the property to '*', just like how we handle svn:executable,
svn:needs-lock, etc. This would also make sure that merges of this property
won't need special handling.
When the inherited-properties branch will be merged to trunk it will be very
easy (and for working copies even a local operation) to determine in which
branch a path is.
Open questions:
* 'svn:branch' or maybe 'svn:root'?
* Which UI do/should we provide in 'svn'
svn cp --branch <PATH-OR-URL> URL
Performs a copy and makes sure there is a svn:branch property on the target
svn mkdir --branch <PATH-OR-URL>
Creates a new branch
* How should we handle 'svn:branch' on multiple levels. E.g. on ^/trunk and
^/trunk/projects/my?
[I don't see a problem with just allowing it as long as we usually only look
up to find the first ancestor]
Feel free to join the design discussion.
Bert
