On 08/23/2013 04:37 PM, Branko Čibej wrote:
> 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.
>
Well as subversion has no branches. My idea was just make URL references
shorter with just some thought on "what if branches were (maybe first
class) citizens". So the chosen naming of potions and property was
misleading.
How these would look like:
1. Ditch -b (--branch) form the original proposal and rename
svn:branches as svn:url-search-roots (or somethin similar/better).
Using ^[name] for URL would just attempt to match an URL in some
(later defined) ways. As of error handling:
svn:externals: If there is an easy way to determine if the user is
sitting in a directory which belongs to svn:externals we just
inform the user that this is not supported.
Name collisions: Just say the user that the name is ambiguous ^/
addressing still can be used.
Syncing issues: Sync the content of the property shall be done
manually. If the team has arranged something and the
(later defined) matcher is not completely dumb, then it
would be a rare thing. Otherwise the user become unlucky
just say that to the user and ^/ addressing still can
be used.
Branching/Copying: As this property would be used at project level
and inherited from there. Regarding normal use cases this shall
shall be no issue. However I admit that if someone uses this
property on lower levels overriding the inherited one, then it
could cause nasty things. In order to prevent that we could just
allow only one svn:url-search-roots definition (inherited or
not) per every path on the repository.
Merge/Conflicts: On normal use cases this shall not happen.
Otherwise just treat the property as any other. The user might
get unlucky again ^/ addressing still can be used.
2. Start to think how can branches be (first class) citizens in
Subversion. ^[branch] could be user there as well.
> 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
>
Received on 2013-08-27 23:00:36 CEST