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:lkisha...@ovi.com]
Sent: Thursday, August 22, 2013 5:15 PM
To: users@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@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
