You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2012/07/16 14:11:10 UTC
RFC: Standardizing a 'svn:branch' (boolean) property
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
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Peter Samuelson <pe...@p12n.org>.
[Philip Martin]
> There needs to be a way to create the initial branch, i.e. mkdir as well
> as copy.
In fact, that's really _all_ that should be needed. If your 'trunk'
has a svn:branch property, and you copy or tag it with 'svn copy', the
target will get the same property. An explicit 'svn copy --branch' is
not useful in that case.
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
>> Open questions:
>> * 'svn:branch' or maybe 'svn:root'?
>
> I'd prefer svn:branch but I don't care strongly.
>
>> * 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
Did you mean to restrict the destination to URLs? Creating branches in
a working copy should be supported.
>>
>> svn mkdir --branch <PATH-OR-URL>
>> Creates a new branch
>
> I would favour a new 'svn branch' subcommand which is equivalent
> to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
There needs to be a way to create the initial branch, i.e. mkdir as well
as copy.
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: maandag 16 juli 2012 17:18
> To: Bert Huijben; dev@subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On 07/16/2012 09:41 AM, Stefan Sperling wrote:
> > On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
> >> Open questions:
> >> * 'svn:branch' or maybe 'svn:root'?
> >
> > I'd prefer svn:branch but I don't care strongly.
>
> And I "svn:branch-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
> >
> > I would favour a new 'svn branch' subcommand which is equivalent
> > to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
>
> Hrm. Here's where I think we see things differently, Stefan. Your
> prescription changes the branching workflow that folks have been using for,
> possibly, a near-decade. I see things more simply: empower and encourage
> users to mark their *trunk* as a branch-root, and now everything follows
> naturally from the existing ('svn cp'-based) workflows. If trunk has the
> svn:branch-root property, every copy thereof will, too.
That would be the ideal workflow, but how do we get the property on that trunk directory initially. For new repositories and for those that users want to enable branch detection on.
That is how I got to this set of two commands with a --branch flag.
Bert
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Trent Nelson <tr...@snakebite.org>.
On Jul 16, 2012, at 11:17 AM, C. Michael Pilato wrote:
> On 07/16/2012 09:41 AM, Stefan Sperling wrote:
>> On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
>>> Open questions:
>>> * 'svn:branch' or maybe 'svn:root'?
>>
>> I'd prefer svn:branch but I don't care strongly.
>
> And I "svn:branch-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
>>
>> I would favour a new 'svn branch' subcommand which is equivalent
>> to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
>
> Hrm. Here's where I think we see things differently, Stefan. Your
> prescription changes the branching workflow that folks have been using for,
> possibly, a near-decade. I see things more simply: empower and encourage
> users to mark their *trunk* as a branch-root, and now everything follows
> naturally from the existing ('svn cp'-based) workflows. If trunk has the
> svn:branch-root property, every copy thereof will, too.
That's exactly how I did it with Enversion. "In the beginning, there was /trunk.". (Or at least, '^.*/trunk$'.)
It worked for ~95% of all cases. There were 3% of repos that never had a trunk, and 2% that had a severely broken branch (i.e. the branch was manually created via mkdir, then random code from other parts of the tree was manually copied over) that unfortunately was still active.
(So, those corner cases have to be handled manually now by Enversion. But, as we have the framework for storing forward-copy information, I've got an enhancement in mind that'll use a heuristic to detect, during analysis, that a really-badly-broken-directory-that-just-happens-to-be-a-branch-root is still in use as in regularly being copied/branched from.)
Trent.
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jul 16, 2012 at 11:17:58AM -0400, C. Michael Pilato wrote:
> On 07/16/2012 09:41 AM, Stefan Sperling wrote:
> > I would favour a new 'svn branch' subcommand which is equivalent
> > to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
>
> Hrm. Here's where I think we see things differently, Stefan. Your
> prescription changes the branching workflow that folks have been using for,
> possibly, a near-decade. I see things more simply: empower and encourage
> users to mark their *trunk* as a branch-root, and now everything follows
> naturally from the existing ('svn cp'-based) workflows. If trunk has the
> svn:branch-root property, every copy thereof will, too.
Ah, yes! You're right, that makes more sense.
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/16/2012 09:41 AM, Stefan Sperling wrote:
> On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
>> Open questions:
>> * 'svn:branch' or maybe 'svn:root'?
>
> I'd prefer svn:branch but I don't care strongly.
And I "svn:branch-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
>
> I would favour a new 'svn branch' subcommand which is equivalent
> to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
Hrm. Here's where I think we see things differently, Stefan. Your
prescription changes the branching workflow that folks have been using for,
possibly, a near-decade. I see things more simply: empower and encourage
users to mark their *trunk* as a branch-root, and now everything follows
naturally from the existing ('svn cp'-based) workflows. If trunk has the
svn:branch-root property, every copy thereof will, too.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
RE: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: maandag 16 juli 2012 15:42
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
> > Open questions:
> > * 'svn:branch' or maybe 'svn:root'?
>
> I'd prefer svn:branch but I don't care strongly.
>
> > * 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
>
> I would favour a new 'svn branch' subcommand which is equivalent
> to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
My initial version of this RFC had 'svn branch', but then I was thinking
that we might only learn which features we want for that command later.
svn switch --relocate had a similar history. It was a quick and dirty search
and replace of a url prefix, which is much cleaner implemented as 'svn
relocate' since 1.7 with a slightly different behavior.
But, It would be nicer if we can get it properly defined now :-)
>
> > * 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]
>
> I would say that first svn:branch prop we find while traversing
> upwards wins. This would allow people to branch and merge within
> subtrees as they can do today.
That was my reasoning,
Bert
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
> Open questions:
> * 'svn:branch' or maybe 'svn:root'?
I'd prefer svn:branch but I don't care strongly.
> * 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
I would favour a new 'svn branch' subcommand which is equivalent
to 'svn copy' including a prop-add of 'svn:branch' at the copy target.
> * 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]
I would say that first svn:branch prop we find while traversing
upwards wins. This would allow people to branch and merge within
subtrees as they can do today.
RE: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: dinsdag 17 juli 2012 02:58
> To: C. Michael Pilato
> Cc: Bert Huijben; dev@subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On Mon, Jul 16, 2012 at 3:33 PM, C. Michael Pilato <cm...@collab.net>
> wrote:
> > On 07/16/2012 08:11 AM, Bert Huijben wrote:
> >> 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.
> >
> > This is not the first time this topic has come up:
> >
> > http://svn.haxx.se/dev/archive-2009-09/0156.shtml
> > http://svn.haxx.se/users/archive-2009-09/0292.shtml
> > http://svn.haxx.se/users/archive-2009-02/0729.shtml
>
> It also came up in some more recent discussion started by Julian:
>
> http://svn.haxx.se/dev/archive-2011-10/0406.shtml
>
> (there was some talk in there of a 'project' or 'branching-space'
> concept, to keep related branches/tags together (and maybe also to
> create a namespace for them), but that might go a bit too far for now
> ... and lots of other complexities are lurking behind those concepts).
>
> >> 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.
> >
> > +1. Let's get the mechanics for recognizing branch roots in place
first.
> > We can worry about additional policy matters later when we have a better
> > idea what our users might require.
>
> +1 to some support for branch identification. But I'm not sure if such
> a simple property will provide that in a good way. OTOH I don't have a
> better suggestion now.
>
> First, a couple of use cases I have in mind if branch-roots can be
identified:
>
> 1) branch-root-relative urls, making possible:
> - branch-root-relative externals
> - branch-root-relative viewspecs
As a branch-root is per definition an ancestor of a node, you can't use it
for anything that you can't already handle using the current relative
externals. (It might take some UI work to make it as user friendly, but
nothing new there).
Viewspecs are a nice topic, but not something that we can solve by a simple
thing like defining a property:)
When the inherited properties branch is merged to trunk we probably want to
define a few more common properties to start using the new feature in svn.
(Original use cases for that were things like extending svn:ignore)
>
> 2) branch-root-relative authz?
> - Say "//" is a wildcard for branch-root:
> [repos://private-dir] # "/private-dir" in any "branch" of repos
> [repos:/tags//dir/public] # "/dir/public" under any "branch" below
> "tags" of repos
> - Dunno if this is technically implementable for authz. So this may be
> a not-so-good use-case :-).
Currently our authz just looks at paths as strings, not at the content of a
repository.
I like the idea though.
(My guess would be that Enversion can handle these cases much easier)
>
> But, with the "marker-property" approach, and following Trent's
> explanation of Enversion, I worry about:
>
> - How to retrofit an existing repository with branch-root
> identification on historical branches/tags? Enversion's solution of
> using revprops seems currently the only way we have to "annotate"
> history.
When you merge, you always merge to HEAD. And we can always change HEAD.
But I see the point that it wouldn't be nice that we would have to change
old tags.
But then, using mutable revision properties for things that you want cached
on the client side for UI-optimization... I don't think that is going to
work.
I don't see a use case yet where we would like to scan history to find old
branch-roots.
Once we know that we want to merge an old/specific url at a specific
revision, we are no longer interested in what is or isn't a branch root.
> - How to automate the annotation of existing branches?
>
> Both of these concerns are less of a problem for new repositories (if
> trunk is marked as branch-root, all new branches/tags created from
> there will be branch-roots as well). But then for new repositories
> there is another concern:
>
> - How to ensure users won't forget to mark their new trunk(s) as
> branch-root(s)? I can perfectly imagine a furious mail to users@
> saying: "I'm at r250000 now, and you're telling me that I should have
> marked 'trunk' with the svn:branch-root property (or should have
> created 'trunk' with 'mkdir --branch') back at r1 to get proper branch
> support for features X, Y and Z??? And I can't correct this situation
> now (historically complete), without doing a dump/reload causing all
> my users to checkout new working copies?"
>
> Finally:
>
> - We wouldn't need "svn copy --branch" would we? Only "svn mkdir
> --branch" and regular "svn copy" (which propagates the marker property
> anyway)? Right?
That leaves the problem: how do we get the property on existing
repositories.
svn copy --branch would allow performing some best practice checks, adding
the property as necessary (and maybe suppressing the automatic subdirectory
creation mentioned by Philip on irc).
I don't think we can just make 'svn copy' fail on common client-side
scenarios, just because we invented a svn:branch-root in 1.8.
svn copy --branch (or svn branch) can have any behavior we want.
Bert
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 17.07.2012 07:14, Trent Nelson wrote:
[a description of Enversion]
Thanks, Trent -- this was a very good description.
So what we have here is a tool that provides additional branch semantics
on top of Subversion's data model and controls commits to protect the
repository against several kinds of changes that break its assumptions.
Which is fine.
Now can someone explain to me why we would want to duplicate Enversion's
functionality in Subversion, given that it's already available under the
same terms as Subversion itself? And if you want to implement just a
subset of what Enversion does, can you guarantee that it's in fact a
safe subset?
I got the feeling that Enversion pretty much has the minimal set of
features it requires; anything less would be incomplete and therefore
cause no end of problems. But it /does/ restrict what Subversion can do,
and for a separate tool, that's not a problem. However, if you want to
implement something similar in Subversion, you'll end up either making a
whole slew of complex features optional, or break backward compatibility.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Trent Nelson <tr...@snakebite.org>.
On 7/17/12 1:14 AM, "Trent Nelson" <tr...@snakebite.org> wrote:
> 7. Once we detect a root is affected, evn:roots is updated
> accordingly. In trac@r175, a new tag is created. Specifically,
> trunk@175 is copied to /tags/trac-0.5-rc1. That results in two
^^^^^^^^^
s/trunk@175/trunk@174/
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Trent Nelson <tr...@snakebite.org>.
On 7/16/12 8:57 PM, "Johan Corveleyn" <jc...@gmail.com> wrote:
>On Mon, Jul 16, 2012 at 3:33 PM, C. Michael Pilato <cm...@collab.net>
>wrote:
>> On 07/16/2012 08:11 AM, Bert Huijben wrote:
>>> 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.
>>
>> +1. Let's get the mechanics for recognizing branch roots in place
>>first.
>> We can worry about additional policy matters later when we have a better
>> idea what our users might require.
>
>+1 to some support for branch identification. But I'm not sure if such
>a simple property will provide that in a good way. OTOH I don't have a
>better suggestion now.
>
>First, a couple of use cases I have in mind if branch-roots can be
>identified:
I've noticed this thread has a lot of focus on "how to identify branch
roots" but not so much on what to do with that information. What are the
specific use cases we want to address?
In my case, I had a client with a *huge* Subversion deployment; nearly a
thousand production repos, tens of thousands of sub-teams, hundreds of
gigabytes of data, etc.
They had an awful experience with merging in particular -- one of the most
prominent teams had to essentially stop development for a few weeks whilst
the SCM admins tried to unbreak their mergeinfo (amongst other things).
50+ developers at 10% productivity x 2+ weeks = expensive.
The-CIO-has-heard-about-this-and-is-super-pissed expensive.
My remit was simple: prevent this sort of problem from ever happening
again. From that, I extrapolated I needed to block a good 20-30 different
types of commits that contributed to "repo entropy". For example:
- TagDirectoryCreatedManually
- BranchDirectoryCreatedManually
- BranchRenamedToTrunk
- TrunkRenamedToBranch
- TrunkRenamedToTag
- BranchRenamedToTag
- BranchRenamedOutsideRootBaseDir
- TagSubtreePathRemoved
- RenameAffectsMultipleRoots
- UncleanRenameAffectsMultipleRoots
- MultipleRootsCopied
- TagCopied
- UncleanCopy
- FileRemovedFromTag
- CopyKnownRootSubtreeToValidAbsRootPath
- MixedRootsNotClarifiedByExternals
- CopyKnownRootToIncorrectlyNamedRootPath
- CopyKnownRootSubtreeToIncorrectlyNamedRootPath
- UnknownPathRenamedToIncorrectlyNamedNewRootPath
- RenamedKnownRootToIncorrectlyNamedRootPath
- MixedChangeTypesInMultiRootCommit
- CopyKnownRootToKnownRootSubtree
(Full list of events currently blocked by Enversion:
http://people.apache.org/~trent/events.py)
Other requirements:
- Minimal administrative overhead. Requiring administrators to
manually specify branch roots (or trying to use regexes when each
repo had an entirely different layout) does not scale when you're
dealing with thousands of repositories. Ditto for requiring dump/
load dances.
- 100% accuracy for branch identification.
- No false negatives. Confidence in Subversion was at an all time
low -- many teams were threatening to ditch it and set up their
own P4/git repo. If anything was introduced that made the user
experience more painful, there would be anarchy.
With all of those requirements set in stone, I came up with the evn:roots
revprop approach. Which, I'm happy to report, has been chugging along in
production at this client's site for about 18 months now. Enversion will
now block some... $(cat events.py | grep '^class ' | wc -l)... 100
different types of commits that contribute to "repo entropy".
For the record, here's an outline of Enversion's evn:roots approach. It
took a few failed attempts before I came up with the design below... but,
as I mentioned, it's been in production for 18+ months on just under a
thousand repos and has met all the original requirements, so I'm pretty
happy with it.
1. Analyze the repository via `evnadmin analyze <repo>`. This
processes rev 0 to HEAD sequentially.
2. "In the beginning, there was /trunk". I'm amazed how much
mileage I got out of this idiom. Essentially, the only way
to 'create' a root from scratch is to `svn mkdir .*/trunk`.
3. Once a .*/trunk mkdir is detected, an evn:roots entry is added
for it in the revprop it was created in. For example, after
analyzing r1 of the trac repo:
% svn pg evn:roots --revprop -r1 `gru trac`
{'/trunk/': {'copies': {},
'created': 1,
'creation_method': 'created'}}
4. When processing the next revision, the roots from the previous
revprop are inherited in a simplified format:
% svn pg evn:roots --revprop -r2 `gru trac`
{'/trunk/': {'created': 1 }}
i.e. the root name and the revision it was created in.
5. Analysis of each subsequent revision always inherits the previous
revision's roots (in the simplified format).
6. With an up-to-date, definitive list of repository roots on hand
each time we process a new revision, we can easily detect if a
revision affects a root. A root can be affected in the following
ways:
- Copied (directly and indirectly).
- Renamed (directly and indirectly).
- Replaced (directly and indirectly).
- Removed (directly and indirectly).
During analysis, we process the revision and update the roots
regardless of the action. However, once analysis is complete
and the hooks are enabled, we can block all the crazy stuff.
This is an important point -- even though the end goal is to
eventually block dodgy commits, we have to process such commits
during analysis and update evn:roots accordingly. You have no
idea how complicated this actually is. There are about seven
extreme corner cases that Enversion still bombs out on --
commits that I never would have thought even remotely possible
until I saw them in the wild.
7. Once we detect a root is affected, evn:roots is updated
accordingly. In trac@r175, a new tag is created. Specifically,
trunk@175 is copied to /tags/trac-0.5-rc1. That results in two
changes.
First, the evn:roots of r175's revprop includes the new root:
% svn pg evn:roots --revprop -r175 `gru trac`
{'/tags/trac-0.5-rc1/': {'copied_from': ('/trunk/', 174),
'copies': {},
'created': 175,
'creation_method': 'copied'},
'/trunk/': {'created': 1}}
Second, we record that trunk was copied. This sort of metadata
is always stored back in the revprop where the root was created,
in this case, r1:
% svn pg evn:roots --revprop -r1 `gru trac`
{'/trunk/': {'copies': {174: [('/tags/trac-0.5-rc1/', 175)]},
'created': 1,
'creation_method': 'created'}}
As analysis continues, the entry for /trunk/ in r1's evn:roots
gets continually updated with relevant actions that affect it.
If a root is detected as being removed (directly or indirectly)
during analysis, a note is made in the originating evn:roots
revprop that it was deleted (with reference to the rev it was
removed in, and the type of removal (i.e. removed directly,
removed indirectly due to ancestory path being removed, etc),
and the root will no longer be inherited in future evn:roots.
As for Enversion, the good news is that it's free, open source, Apache 2.0
licensed and available on github. The bad news is that it's poorly
documented at the moment and the installation is a bit fiddly:
% git clone https://github.com/tpn/enversion.git
Cloning into 'enversion'...
remote: Counting objects: 56, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 56 (delta 6), reused 55 (delta 5)
Unpacking objects: 100% (56/56), done.
% export PYTHONPATH=$PYTHONPATH:`pwd`/enversion
% export PATH=$PATH:`pwd`/enversion/bin
% evnadmin
Type 'evnadmin <subcommand> help' for help on a specific subcommand.
Available subcommands:
analyze
create
disable-remote-debug (drd)
doctest
[snip]
If you get that far, you'll be able to create a new Enversion-enabled
repository, or analyze an existing one. See (the incredibly terse)
https://github.com/tpn/enversion/blob/master/doc/quick-start.rst for a few
more hints.
FWIW, Snakebite sucks up 110% of my time at the moment, so I'm having to
neglect Enversion a bit. I'll be ramping back up on it soon, though. I'd
still love to hear from people having a play with it. It's production
ready from a functionality perspective, but definitely alpha quality from
a installer/documentation/docstrings/unit-tests perspective. Although
that's primarily a result of only being funded for 20 days rather than
negligence on my part ;-)
Regards,
Trent.
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Jul 16, 2012 at 3:33 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/16/2012 08:11 AM, Bert Huijben wrote:
>> 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.
>
> This is not the first time this topic has come up:
>
> http://svn.haxx.se/dev/archive-2009-09/0156.shtml
> http://svn.haxx.se/users/archive-2009-09/0292.shtml
> http://svn.haxx.se/users/archive-2009-02/0729.shtml
It also came up in some more recent discussion started by Julian:
http://svn.haxx.se/dev/archive-2011-10/0406.shtml
(there was some talk in there of a 'project' or 'branching-space'
concept, to keep related branches/tags together (and maybe also to
create a namespace for them), but that might go a bit too far for now
... and lots of other complexities are lurking behind those concepts).
>> 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.
>
> +1. Let's get the mechanics for recognizing branch roots in place first.
> We can worry about additional policy matters later when we have a better
> idea what our users might require.
+1 to some support for branch identification. But I'm not sure if such
a simple property will provide that in a good way. OTOH I don't have a
better suggestion now.
First, a couple of use cases I have in mind if branch-roots can be identified:
1) branch-root-relative urls, making possible:
- branch-root-relative externals
- branch-root-relative viewspecs
2) branch-root-relative authz?
- Say "//" is a wildcard for branch-root:
[repos://private-dir] # "/private-dir" in any "branch" of repos
[repos:/tags//dir/public] # "/dir/public" under any "branch" below
"tags" of repos
- Dunno if this is technically implementable for authz. So this may be
a not-so-good use-case :-).
But, with the "marker-property" approach, and following Trent's
explanation of Enversion, I worry about:
- How to retrofit an existing repository with branch-root
identification on historical branches/tags? Enversion's solution of
using revprops seems currently the only way we have to "annotate"
history.
- How to automate the annotation of existing branches?
Both of these concerns are less of a problem for new repositories (if
trunk is marked as branch-root, all new branches/tags created from
there will be branch-roots as well). But then for new repositories
there is another concern:
- How to ensure users won't forget to mark their new trunk(s) as
branch-root(s)? I can perfectly imagine a furious mail to users@
saying: "I'm at r250000 now, and you're telling me that I should have
marked 'trunk' with the svn:branch-root property (or should have
created 'trunk' with 'mkdir --branch') back at r1 to get proper branch
support for features X, Y and Z??? And I can't correct this situation
now (historically complete), without doing a dump/reload causing all
my users to checkout new working copies?"
Finally:
- We wouldn't need "svn copy --branch" would we? Only "svn mkdir
--branch" and regular "svn copy" (which propagates the marker property
anyway)? Right?
--
Johan
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/16/2012 08:11 AM, Bert Huijben wrote:
> 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.
This is not the first time this topic has come up:
http://svn.haxx.se/dev/archive-2009-09/0156.shtml
http://svn.haxx.se/users/archive-2009-09/0292.shtml
http://svn.haxx.se/users/archive-2009-02/0729.shtml
> 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.
+1. Let's get the mechanics for recognizing branch roots in place first.
We can worry about additional policy matters later when we have a better
idea what our users might require.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 18, 2012 at 1:13 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 17.07.2012 22:55, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 17.07.2012 21:08, Julian Foad wrote:
>>>> I know it would be nice and convenient if it was defined centrally
>>>> here, but ... I dunno, others may disagree, but I think we need a much
>>>> more rigorous definition before I'd be happy to consider it.
>>> Thank you, Julian, for putting it so clearly.
>> Yeah, well, it seems some people -- cmpilato for one -- do have some non-shallow thoughts about this subject. C-Mike said on IRC:
>>
>> julianf: I think you're looking at things backward. Or maybe I am. I don't want users' haphazard behaviors to inform the server about what appears to be a branch-root. I want a person -- the same person who would fire off the angry email to the idiot that merged and committed a subtree -- to say up front: "Here's our branch-root, server (and client). Now protect it!"
>> I guess what I want is Enversion semantics, implement in Subversion's core with prelim enforcement in the client (as opposed to in a hook script that can only fire after users upload 50Meg of ill-aimed merge commit info).
>
> I think there are two ways of approaching this problem: one is to
> consciously break backwards compatibility, introduce first-class
> branches in a separate namespace from the tree, and only allow merging
> between branches. This would simplify the data model enormously, but I'm
> not sure it's even possible to create a sane migration tool from the
> current data model to this one.
I'd be interested in hearing more about how you envision first-class branches.
I guess that would require more fundamental work accross the board
(FS, server, protocol, client). But regardless (and ignoring for a
minute how hard it would be to migrate existing repositories), I'd be
interested in hearing more details of how this could fit into
Subversion conceptually. That way, we could have more of an informed
discussion considering the various options.
Concerning migration, I think there would be roughly 3 options:
1) 1st class branches introduce new stuff in SVN that make in not
backward compatible with current repositories -> hence 2.0
2) 1st class branches can be made interoperable with 1.x, but we don't
migrate anything -> you can use the feature for any new branches you
create
3) 1st class branches can be made interoperable with 1.x, but we offer
a way to migrate existing branches
> The other way, which you propose, I'm still trying to understand the
> reasons for. I'm very much guessing that they can be grouped as follows:
>
> 1. Disallow the kinds of branches and consequently merges that
> currently do not work correctly;
> 2. Simplify branch identification for users
> 3. Simplify merge commands
>
> Of the above, I can empathise with points 2 and 3. But point 1 should be
> solved without introducing this new feature. I'm not saying it's going
> to be trivial, and I won't hijack this thread by going into details.
Another interesting thing (also suggested by Julian [1]) would be that
branches should not only be identified as branches, but also
identified as part of a certain context, project, branch namespace or
whatever you want to call it. So users can create more structure in
their branches (and only merge between branches of the same
branching-space), similar to how they can now order branches in
directories under ^/branches, but then in a clearly specified way (and
usable to enforce certain things, for merging for example).
That is not addressed by the proposal that started this thread. But
then again, I don't know how important that kind of structure would
be, or if it would be used much in practice (there is probably a lot
more to be discussed before diving into something like this ... a
topic for another thread I guess).
[1] http://svn.haxx.se/dev/archive-2011-10/0406.shtml
--
Johan
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 17.07.2012 22:55, Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.07.2012 21:08, Julian Foad wrote:
>>> I know it would be nice and convenient if it was defined centrally
>>> here, but ... I dunno, others may disagree, but I think we need a much
>>> more rigorous definition before I'd be happy to consider it.
>> Thank you, Julian, for putting it so clearly.
> Yeah, well, it seems some people -- cmpilato for one -- do have some non-shallow thoughts about this subject. C-Mike said on IRC:
>
> julianf: I think you're looking at things backward. Or maybe I am. I don't want users' haphazard behaviors to inform the server about what appears to be a branch-root. I want a person -- the same person who would fire off the angry email to the idiot that merged and committed a subtree -- to say up front: "Here's our branch-root, server (and client). Now protect it!"
> I guess what I want is Enversion semantics, implement in Subversion's core with prelim enforcement in the client (as opposed to in a hook script that can only fire after users upload 50Meg of ill-aimed merge commit info).
I think there are two ways of approaching this problem: one is to
consciously break backwards compatibility, introduce first-class
branches in a separate namespace from the tree, and only allow merging
between branches. This would simplify the data model enormously, but I'm
not sure it's even possible to create a sane migration tool from the
current data model to this one.
The other way, which you propose, I'm still trying to understand the
reasons for. I'm very much guessing that they can be grouped as follows:
1. Disallow the kinds of branches and consequently merges that
currently do not work correctly;
2. Simplify branch identification for users
3. Simplify merge commands
Of the above, I can empathise with points 2 and 3. But point 1 should be
solved without introducing this new feature. I'm not saying it's going
to be trivial, and I won't hijack this thread by going into details.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> On 17.07.2012 21:08, Julian Foad wrote:
>> I know it would be nice and convenient if it was defined centrally
>> here, but ... I dunno, others may disagree, but I think we need a much
>> more rigorous definition before I'd be happy to consider it.
>
> Thank you, Julian, for putting it so clearly.
Yeah, well, it seems some people -- cmpilato for one -- do have some non-shallow thoughts about this subject. C-Mike said on IRC:
julianf: I think you're looking at things backward. Or maybe I am. I don't want users' haphazard behaviors to inform the server about what appears to be a branch-root. I want a person -- the same person who would fire off the angry email to the idiot that merged and committed a subtree -- to say up front: "Here's our branch-root, server (and client). Now protect it!"
I guess what I want is Enversion semantics, implement in Subversion's core with prelim enforcement in the client (as opposed to in a hook script that can only fire after users upload 50Meg of ill-aimed merge commit info).
(From <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-07-17#l261>.)
May the discussion yet bear fruit.
- Julian
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 17.07.2012 21:08, Julian Foad wrote:
> I know it would be nice and convenient if it was defined centrally
> here, but ... I dunno, others may disagree, but I think we need a much
> more rigorous definition before I'd be happy to consider it.
Thank you, Julian, for putting it so clearly.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Julian Foad <ju...@btopenworld.com>.
Bert Huijben wrote:
> 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. [...]
>
> 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
I wasn't going to respond to this thread but I got sucked in :-)
I think the idea of simply tagging certain nodes in certain revisions as "this is a branch root" is ridiculously weak. I agree it would *work* to the extent of being able to implement some simple UI hints such as
"You want to merge 'update-editor.c' but it isn't marked as a branch root, but 'trunk' is, so merge at that level instead?"
But it seems so hacky and limited.
Limited for example in that I would want to be able to ask not only "is this a branch root" (or "where are the branch roots between this path and ^/"), but also "where will I find the other branches of this (project|branched-thing)?" Maybe the other branches of *this* (project|branched-thing) are mixed up with branches of other (projects|branched-things).
Hacky in that I have seen hardly any semantics mentioned. What does it mean to say that a node is a "branch root"? Does it mean "somebody has done a merge to or from this node in the past"? "Somebody thinks they might want to merge to or from this node in the future"? "This node shares a common copy-from ancestor with one or more (unspecified) other nodes in the repository"?
If more and more people keep doing merges over time, sometimes using the "wrong" root (on purpose or by accident), and sometimes press the "Please mark this as a branch root for future use" button, then over time you'll find that "update-editor.c", "libsvn_wc", "subversion" and "trunk" all have that property set. Then where are we?
[Bert responded: "Same as where we are right now."]
If we can set this property on an already-existing trunk or branch, then what about old versions -- does it not matter to anybody that the old versions are not marked? It would matter to me if I were writing a client that includes any kind of history browsing.
On IRC just now [1], Bert talked about storage and transmission of "this is a branch root" data, arguing that a versioned prop is good because the client can see the value immediately and that the 'enversion'[2] way, which is using revprops, is not good because of the difficulty of reliably caching revprops on the client for fast look-up. To me, those are valid implementation concerns but almost orthogonal to the design issue of what semantics we should be providing.
Bert said, "Then just lets see if we can get better than the current 'we don't know if there is a root'. Currently Subclipse has 'subclipse:tags' property, AnkhSVN has 'vsroject-root' [...].
I suppose the other way to respond is that this idea doesn't seem suitable as a core piece of Subversion design, but it doesn't need to be: it's a client-specific feature. You can certainly define a common name for a branch-root boolean property, to be shared by several svn clients. Talk to those other clients' teams and choose a name. The name should not start with "svn:".
I know it would be nice and convenient if it was defined centrally here, but ... I dunno, others may disagree, but I think we need a much more rigorous definition before I'd be happy to consider it.
- Julian
[1] IRC conversation starting at <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-07-17#l106>.
--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Greg Stein <gs...@gmail.com>.
On Jul 17, 2012 1:27 AM, "Branko Čibej" <br...@wandisco.com> wrote:
>
> On 17.07.2012 03:59, Greg Stein wrote:
>...
> They're not, to me. This looks like another case of having an "obviously
> correct" solution in hand without having thought about the ramifications.
Oh, I know what you mean, and tend to agree. I'm commenting on the
community process rather than this instance.
> We've historically more or less required to have a design doc written up
> before going into implementation details of major new features.
Euh... no, we haven't.
wc_db.h and Ev2 were designed by header. WC-NG would have been impossible
to design up front. It was a continual research and implementation project.
We had a desired outcome, but that wasn't really written down. I don't
recall docs for patch or svnrdump.
I could reach further into the past, but it doesn't matter. Gating somebody
is improper. You can say "that's wrong" as often as you'd like (other
Apache communities might call it a veto, but we're nicer and more
cooperative :-), and you don't even have to give an alternative. But it
still doesn't mean you can demand a long list of requirements and
documentation. Your (a) thru (e) and "explore other" and "think" crossed
the line, I would say. We want discussion, sure, and maybe that stuff can
help focus the community. It just isn't proper as a requirement.
We are Commit-Then-Review (CTR), not RTC.
Cheers,
-g
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 17.07.2012 03:59, Greg Stein wrote:
> On Jul 16, 2012 1:18 PM, "Branko Čibej" <br...@wandisco.com> wrote:
>> ...
>> Please describe the set of use cases you want to address, propose how
>> you think this new property can solve them, and at the very least,
>> explain how the solution will affect: a) the command-line client, b)
>> every other client, c) branching and merging, d) sparse checkouts, e)
>> externals. And explore other usage models than the one you have in mind
>> and think about how the proposed change will affect them.
> I want to make a community meta-comment here:
>
> It is fair to say "it won't work because $foo."
>
> It is not fair to say "before scratching your itch, you must satisfy *my*
> half-dozen requirements."
My problem is that right now I can't even see, from this discussion, how
exactly that itch is supposed to be scratched. Everyone else seems to
already have a specific solution in mind and are already talking about
implementation details, as if semantics and side effects were trivially
obvious.
They're not, to me. This looks like another case of having an "obviously
correct" solution in hand without having thought about the ramifications.
We've historically more or less required to have a design doc written up
before going into implementation details of major new features. Why
would waive that for this particular case?
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Greg Stein <gs...@gmail.com>.
On Jul 16, 2012 1:18 PM, "Branko Čibej" <br...@wandisco.com> wrote:
>...
> Please describe the set of use cases you want to address, propose how
> you think this new property can solve them, and at the very least,
> explain how the solution will affect: a) the command-line client, b)
> every other client, c) branching and merging, d) sparse checkouts, e)
> externals. And explore other usage models than the one you have in mind
> and think about how the proposed change will affect them.
I want to make a community meta-comment here:
It is fair to say "it won't work because $foo."
It is not fair to say "before scratching your itch, you must satisfy *my*
half-dozen requirements."
We contribute on our own time, but those contributions cannot be gated by
others a priori. We ask for discussion and consensus before large
conceptual changes, but there are many ways to get to a rough consensus
before implementation begins. And that doesn't usually require a whitepaper.
Cheers,
-g
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 16.07.2012 19:51, Bert Huijben wrote:
> 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.
I said that directories /aren't/ 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.
This appears to be a case where one solution can never solve all the
extant use-cases. If you introduce such a property and, e.g., map
Subclipse's functionality onto it, you're going to cause trouble for a
bunch of other users.
Besides, I really don't like this "design by example" or "design by
so-and-so has it" approach. We've done that in the past (changesets,
anyone?) and the results turned out to be less than widely useful.
Please describe the set of use cases you want to address, propose how
you think this new property can solve them, and at the very least,
explain how the solution will affect: a) the command-line client, b)
every other client, c) branching and merging, d) sparse checkouts, e)
externals. And explore other usage models than the one you have in mind
and think about how the proposed change will affect them.
Like it or not, Subversion has a complex data model and many features
that make edge cases where at first you wouldn't expect them. As a case
in point, consider that we've been doing merge tracking for more than 6
years and /still/ haven't got it right, and it'll take at least another
year to really make merging work the way it should. And that's not for
lack of trying; it's simply the result of the data model being more
complex than even the authors imagined.
BTW, I have no idea how inherited properties have any bearing on this
discussion. Surely you're not advocating to make svn:branch inherited,
without even knowing what the semantics of inherited properties is going
to be?
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: maandag 16 juli 2012 21:52
> To: Daniel Shahaf
> Cc: Bert Huijben; 'Branko Čibej'; dev@subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On 07/16/2012 03:41 PM, Daniel Shahaf wrote:
> > Bert Huijben wrote on Mon, Jul 16, 2012 at 19:51:59 +0200:
> >> 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?
> >
> > The highest (closest-to-root) level that has svn:mergeinfo set.
>
> Huh? Most trunks won't have mergeinfo on them unless they've been the
> recipient of a merge from elsewhere.
Just checking a few real world repositories and yes, trunk doesn't have svn:mergeinfo in my 'normal' usecases.
And I think this would certainly apply to about every repository where one is experimenting with the tools to find out whether they want to use it or not.
Bert
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/16/2012 03:41 PM, Daniel Shahaf wrote:
> Bert Huijben wrote on Mon, Jul 16, 2012 at 19:51:59 +0200:
>> 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?
>
> The highest (closest-to-root) level that has svn:mergeinfo set.
Huh? Most trunks won't have mergeinfo on them unless they've been the
recipient of a merge from elsewhere.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Daniel Shahaf <da...@elego.de>.
Bert Huijben wrote on Mon, Jul 16, 2012 at 19:51:59 +0200:
>
>
> > -----Original Message-----
> > From: Branko Čibej [mailto:brane@wandisco.com]
> > Sent: maandag 16 juli 2012 19:08
> > To: dev@subversion.apache.org
> > Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
> >
> > On 16.07.2012 14:11, Bert Huijben wrote:
> > > 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.
> >
> > This idea looks to me very much like a solution looking for a problem.
> >
> > First of all: which problem, specifically, are you trying to solve? And
> > how can this problem not be solved today by inspecting svn:mergeinfo?
>
> 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?
The highest (closest-to-root) level that has svn:mergeinfo set.
RE: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@wandisco.com]
> Sent: maandag 16 juli 2012 19:08
> To: dev@subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> On 16.07.2012 14:11, Bert Huijben wrote:
> > 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.
>
> This idea looks to me very much like a solution looking for a problem.
>
> First of all: which problem, specifically, are you trying to solve? And
> how can this problem not be solved today by inspecting svn:mergeinfo?
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?
If we guess wrong the user can't build or use this project.
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.
(Currently we guess based on directory names and subversion client specific properties)
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.
>
> Regardless of what we tell users, there are a few things that we have to
> understand about Subversion's data model before we proceed with any
> discussion of branch-foo-like features:
>
> * Directories are not branches. /Copies/ of nodes (not only
> directories) represent branch points, and the difference is significant.
> * Subversion does not have named branches. Paths are only incidentally
> useful for hinting at branch identity, but are far from definitive,
> as Julian will happily tell you at some length. :)
> * Even if, for the sake of argument, we assume that directory names
> can be used equivalently to branch names, you still have to take
> into account that the /contents/ of a directory can have a
> completely different branch history than the directory itself.
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.
Bert
> Incidentally, the above points are the reason why a mapping from
> Subversion's current data model to one where branches are top-level,
> first-class objects in a separate namespace is very hard and may prove
> to be impossible. The idea of an svn:branch property seems to assume
> that such a mapping is possible; but I would like to see something more
> rigorous than "client tools could really use some hint" before believing
> that such a property would solve any case that cannot be solved by
> information available to clients today.
>
> -- Brane
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Branko Čibej <br...@wandisco.com>.
On 16.07.2012 14:11, Bert Huijben wrote:
> 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.
This idea looks to me very much like a solution looking for a problem.
First of all: which problem, specifically, are you trying to solve? And
how can this problem not be solved today by inspecting svn:mergeinfo?
Regardless of what we tell users, there are a few things that we have to
understand about Subversion's data model before we proceed with any
discussion of branch-foo-like features:
* Directories are not branches. /Copies/ of nodes (not only
directories) represent branch points, and the difference is significant.
* Subversion does not have named branches. Paths are only incidentally
useful for hinting at branch identity, but are far from definitive,
as Julian will happily tell you at some length. :)
* Even if, for the sake of argument, we assume that directory names
can be used equivalently to branch names, you still have to take
into account that the /contents/ of a directory can have a
completely different branch history than the directory itself.
Incidentally, the above points are the reason why a mapping from
Subversion's current data model to one where branches are top-level,
first-class objects in a separate namespace is very hard and may prove
to be impossible. The idea of an svn:branch property seems to assume
that such a mapping is possible; but I would like to see something more
rigorous than "client tools could really use some hint" before believing
that such a property would solve any case that cannot be solved by
information available to clients today.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Standardizing a 'svn:branch' (boolean) property
Posted by Trent Nelson <tr...@snakebite.org>.
On Jul 16, 2012, at 8:11 AM, Bert Huijben wrote:
> 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.
Automatic branch ("root") identification is Enversion's bread and butter, so I might as well weigh in here.
Here's an example I've copied from [1]:
% evnadmin root-info /trunk trac
Looking up root '/trunk' in repository 'trac'...
Found '/trunk' in r10932's roots; created in r1.
Displaying root info for '/trunk' from r1:
{'/trunk/': {
'created': 1,
'creation_method': 'created',
'copies': {
174: [('/tags/trac-0.5-rc1/', 175)],
182: [('/tags/trac-0.5/', 183)],
192: [('/tags/trac-0.5.1/', 193)],
...
1086: [('/branches/0.8-stable/', 1087)],
1185: [('/branches/cmlenz-dev/rearch/', 1186)],
1351: [('/branches/cboos-dev/xref-branch/', 1352)],
1370: [('/branches/cmlenz-dev/vclayer/', 1371)],
...
9871: [('/tags/trac-0.12/', 9872)],
9937: [('/branches/0.12-stable/', 9938)],
10647: [('/sandbox/ticket-3584/', 10648)],
10649: [('/sandbox/ticket-3580/', 10650)]
},
}}
That information (a safe Python dict) happens to be stored in a cumulative revprop called evn:roots. Each revision's evn:roots revprop is populated during the repository analysis process (`evnadmin analyze <repo>`).
The main difference between this approach and the approach you mentioned is that Enversion goes to extremes in order to avoid the need for manual intervention. i.e. the need for an administrator or power-user to come in and manually mark specific paths as 'roots'. I talk more about the motivation behind this approach in [2].
Having a cumulative revprop worked well because it catered for, say `svn cp ^/trunk@50 ^/branches/foo` when HEAD is 100 and svn:branch was set at r90. r50 has no svn:branch set, so /branches/foo doesn't pick up the 'I-am-a-root' metadata.
....which reminds me, I really should spend some time trying to get the word out about Enversion ;-)
Trent.
[1]: https://github.com/tpn/enversion/blob/master/doc/quick-start.rst
[2]: http://svn.haxx.se/dev/archive-2011-10/0107.shtml