On 23.08.2013 16:06, Andrew Reedick wrote:
>
>> -----Original Message-----
>> From: Laszlo Kishalmi [mailto:lkishalmi_at_ovi.com]
>> Sent: Thursday, August 22, 2013 5:15 PM
>> To: users_at_subversion.apache.org
>> Subject: Feature Req: sorthand urls for branches/tags in CLI
>>
>>
>>
>> Implementation ideas:
>> We put a specific property on project1 folder let's call it
>> svn:branches for now. Here we could describe the layout of
>> branches and tags for that part of repository. E.g.:
>> a) Using prefixes:
>> /
>> /branches/
>> /tags/
>> b) Using some custom mapping/lists:
>> trunk
>> branches/*
>> tags/*
>> c) Using regexp captures:
>> (trunk)
>> branches/(\w+)
>> tags/(\w+)
>> Having this info, the path where this property is set, the name
>> of the branch and the current path relative to wc root it is
>> possible to construct a repository URL to be used.
>>
>> As far as I currently see there would be no change required on server
>> side.
>>
> Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a "-b" option. It's still an interesting idea, though.
>
> What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly.
> What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither?
>
> Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using "-b foo" in place of "^/branches/foo". Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use.
Actually I find the idea of having a single propery to define project
layout totally wrong. What if, at a later date, you change the project
structure? Who is responsible for updating the property? How do you keep
it in sync with reality? How do you detect that it's out of sync?
Those are just a few considerations that have to be addressed, and
frankly I don't think there's any sane way of addressing them. This is
like the svn:externals mess all over again.
It would be much safer IMO if the root of each branch were identified by
a property instead. For example: we could introduce an svn:branch
property that can be set only on directories. The presence of such a
property tells the client and server that the directory is a branch and
should be treated specially. The property could not be manipulated
directly via propset or propedit, but only through branch-specific
commands; for example:
* svn mkdir --branch
Creates a new directory with the svn:branch property set, with an
empty value
Example: svn mkdir --branch http://host/repo/trunk
* svn copy
If the source is a branch, the target also becomes a branch. The
value of the target's svn:branch property is the path_at_revision of
the source (thus, the client and server can easily recognize related
branches and branch points). Using property inheritance, client and
server can enforce constraints on allowed branching (e.g., forbid
branching into a copy of the source branch)
* svn move
Can implement restrictions upon where branches can be moved to,
similar to "svn copy"
* svn diff, svn merge, svn switch
These commands could make use of a (new) shorthand syntax to
identify branches, based on their (base)name and the presence of the
svn:branch property.
We actually had quite a fight^Winteresting discussion about this at the
Berlin hackathon this year.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-08-23 16:38:23 CEST