Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

[Andrew Reedick]

Problem: Subversion doesn't have branches.

Subversion has directory objects, and we Humans(tm) arbitrarily decide that some directories are "branches," thereby giving these directories (branches) magical powers and mystical significance. Meanwhile, Subversion grinds on, treating those magic branches as mundane directories.

You can see the effects of this problem when you change a parent directory common to multiple branches, e.g. changing "/projectFoo/branches" to "/projectBar/branches" will cause every "branch" in "/projectBar/branches/*" to have a shared revision. This complicates finding branch points (--stop-on-copy), finding the common ancestor, etc..

Are there any plans to address this issue or otherwise make branches a first class object? Or at least add a switch to 'svn log' to skip over extraneous "only the parent dir path changed" revisions?

Demonstration:

$ svn mkdir -m "" ^/project1/branches
Committed revision 73.
$ svn mkdir -m "" ^/project1/branches/alpha
Committed revision 74.
$ svn mkdir -m "" ^/project1/branches/beta
Committed revision 75.
$ svn log -q -v ^/project1/branches/alpha
------------------------------------------------------------------------
r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line
Changed paths:
A /project1/branches/alpha
------------------------------------------------------------------------
$ svn log -q -v ^/project1/branches/beta
------------------------------------------------------------------------
r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
Changed paths:
A /project1/branches/beta
------------------------------------------------------------------------

As you can see from the svn logs, the "alpha" and "beta" branches are completely independent. They have no revisions in common.

But by renaming the parent "project1" dir to "project100", we create a linkage between the two:
$ svn mv -m "" ^/project1 ^/project100
Committed revision 76.
$ svn log ^/project100/branches/alpha
------------------------------------------------------------------------
r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
D /project1
A /project100 (from /project1:75)
------------------------------------------------------------------------
r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013)
Changed paths:
A /project1/branches/alpha
------------------------------------------------------------------------

$ svn log ^/project100/branches/beta
------------------------------------------------------------------------
r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
D /project1
A /project100 (from /project1:75)
------------------------------------------------------------------------
r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
Changed paths:
A /project1/branches/beta
------------------------------------------------------------------------

Note that the independent branches "alpha" and "beta" now have revision 76 in common... even though neither branch was changed.

Adding insult to injury, "svn log --stop-on-copy" will stop on revision 76, i.e. it treats r76 as a branch point:

$ svn log --stop-on-copy -v ^/project100/branches/alpha
------------------------------------------------------------------------
r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
D /project1
A /project100 (from /project1:75)
------------------------------------------------------------------------
$ svn log --stop-on-copy -v ^/project100/branches/beta
------------------------------------------------------------------------
r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
Changed paths:
D /project1
A /project100 (from /project1:75)
------------------------------------------------------------------------

As you can see, the "independent" alpha and beta branches now have revision 76 in common. All because Subversion doesn't have branches.

/grumble

[Branko Čibej]

Well, given that you have not created any branches, this works as
expected :)
There are no branch points in your repository; only directories. A
branch is created by copying a directory (with "svn copy"), not by
creating it (with "svn mkdir"), and that is why your --stop-on-copy
works the way it does -- the only copy is a side effect of the rename
(which is currently represented as copy+delete), hence --stop-on-copy
stops ... when it sees the copy.

The real problem here is that Subversion does not treat /renames/ as
atomic operations. This is indeed being addressed, but a complete
solution will take time. I'm not going to go into technical details
here; if you're interested, you're welcome to join the dev@ list and
listen in (or participate) in the discussions there.

In the meantime, Subversion 1.8 will go part of the way towards properly
supporting renames: it will track renames in the working copy, with "svn
status" annotating deletes and copies with rename source/target info,
and will, for example, prevent users from committing only half of a
rename. To go the rest of the way, we'll need rename support on the
server side and -- most significantly -- in the merge module.

-- Brane

P.S.: I agree that --stop-on-copy is an awkward UI for branch point
detection; but that's another topic altogether.

--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

[Andrew Reedick]

> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Thursday, May 09, 2013 4:35 PM
> To: us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>
> Well, given that you have not created any branches, this works as
> expected :) There are no branch points in your repository; only
> directories. A branch is created by copying a directory (with "svn
> copy"), not by creating it (with "svn mkdir"), and that is why your --
> stop-on-copy works the way it does -- the only copy is a side effect of
> the rename (which is currently represented as copy+delete), hence --
> stop-on-copy stops ... when it sees the copy.

No, the effect is the same whether you use 'svn mkdir', 'svn copy', or 'svn mv', for single dirs or for trees full of files and subdirs. If you change the name or path of a parent dir, you implicitly create a common revision across each and every subdir and file. If you "svn mv ^/tag ^/tags" or "svn mv ^/branches ^/project1/branches" then everything under /tags or /project1/branches will now have a new, common, revision according to 'svn log'.

It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.)

I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion.

Anyway, if you never restructure your high-level tags/branches/trunk dir structure and if you never rename a branch or tag, then you won't see this problem.

> The real problem here is that Subversion does not treat /renames/ as
> atomic operations. This is indeed being addressed, but a complete
> solution will take time. I'm not going to go into technical details
> here; if you're interested, you're welcome to join the dev@ list and
> listen in (or participate) in the discussions there.

Yeah, I'm aware of the rename issue (I have a background in ClearCase,) but the 'lack of branches' is a whole issue in and of itself. A branch really should be a walled off garden until you explicitly merge.

[Stefan Sperling]

On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote:
> It's not a huge problem, but in the real world (i.e. a non-contrived
> example) I have branches that have been locked and untouched for
> months that now have a new HEAD revision. And those branches, which
> are supposed to be walled off from each other until explicitly merged,
> now have a revision in common. (*Every* file and dir in the branches
> and tags dir trees now has the new, shared rev.)

It is strange behaviour on a conceptual level if you are used to
thinking in terms of other version control systems (such as ClearCase
in your case).

However, it is a natural consequence of the way Subversion is currently
supposed to represent the concepts of versioning files and directories,
and labels and branches. And it has done so for over a decade. Changing
this behaviour is far from trivial.

I'm not entirely sure what kind of answer you are hoping to get.
Are you happy with the answer that Subversion is simply not ClearCase?

[Branko Čibej]

I can understand that having the "Revision" in "svn info" output change
on what you expect is a conceptually read-only branch can be confusing.
It's also unfortunate that the sort of refactoring mentioned (moving the
branch root directory, for example) will disappoint users who expect to
use --stop-on-copy for branch point detection. Proper rename tracking
should, at least, avoid that issue.

Having first-class branches would be nice (I've often said so), but
they'd probably have to be implemented as an extension orthogonal to the
current versioned-tree model.

-- Brane

[Les Mikesell]

On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>>
> It's not a huge problem, but in the real world (i.e. a non-contrived example) I have branches that have been locked and untouched for months that now have a new HEAD revision. And those branches, which are supposed to be walled off from each other until explicitly merged, now have a revision in common. (*Every* file and dir in the branches and tags dir trees now has the new, shared rev.)
>
> I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion.

Isn't this just a difference in subversion's and your thinking about
the significance of the path change? Subversion is going to see the
path change affecting everything below it because of the way it holds
projects together. Is there some reason you are changing a common
parent path and thinking that it should not affect everything below?
Is it 'above' what you think of as the actual project?

--
Les Mikesell
lesmi...@gmail.com

[Andrew Reedick]

> -----Original Message-----
> From: Stefan Sperling [mailto:st...@elego.de]
> Sent: Friday, May 10, 2013 9:57 AM
> To: Andrew Reedick
> Cc: Branko Čibej; us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

I've been using svn since 1.3, so I'm aware of the design limitations. And yes, I would recommend svn over clearcase in most situations.

Anyway, the whole exercise started when I needed a report script to find the common ancestor between two branches and ran into the 'parent dir change false revision' issue. Then I started going through potential edge cases and realized just how fragile svn branches were (where fragile == dependent on human processes and conventions.) Which in turn made me realize just how basic (i.e. bare metal) svn is in regards to "meta-features" such as branching, tagging, baselines, workflows, etc.. It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.)

[Stefan Sperling]

On Fri, May 10, 2013 at 10:20:54AM -0500, Andrew Reedick wrote:
> It makes me wonder if it would make sense to slap a
> higher-level interface on top of svn in order to implement the process
> aspects of version control (and otherwise hide/keep the lower level
> details/quirks away from users.)

Yes, that makes sense.

Subversion doesn't know anything about process. It only cares about
version control. Process aspects are left to higher-level tools.

For example, Subversion is often tied to an issue tracker, with a
pre-commit hook that requires an issue number in the log message
and then checks the status if the issue to decide whether the
commit should be allowed according to policy.

Or people use hook scripts such as this one:
http://svn.haxx.se/dev/archive-2012-04/0392.shtml
http://svn.haxx.se/dev/archive-2012-04/0394.shtml

I've also seen custom Subversion clients written to support a
particular process.

[Andrew Reedick]

> -----Original Message-----
> From: Les Mikesell [mailto:lesmi...@gmail.com]
> Sent: Friday, May 10, 2013 11:00 AM
> To: Andrew Reedick

> Cc: Branko Čibej; us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving "/trunk" to "/project1/trunk" shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline.

So, from a technical point of view, where "svn has dirs, not branches," then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did.

Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects.

[Les Mikesell]

On Fri, May 10, 2013 at 10:42 AM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>
>> Isn't this just a difference in subversion's and your thinking about
>> the significance of the path change? Subversion is going to see the
>> path change affecting everything below it because of the way it holds
>> projects together. Is there some reason you are changing a common
>> parent path and thinking that it should not affect everything below?
>> Is it 'above' what you think of as the actual project?
>>
>
> Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving "/trunk" to "/project1/trunk" shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline.
>

How/why do you think of that differently than doing a similar
directory move/rename somewhere under trunk?

> So, from a technical point of view, where "svn has dirs, not branches," then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did.

You think some directories are magically different (i.e. where your
idea of a 'project' starts). Subversion doesn't.

> Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects.

I think it is one less thing to think about when all directories are
handled the same way.

--
Les Mikesell
lesmi...@gmail.com

[Varnau, Steve (Seaquest R&D)]

-Steve

> -----Original Message-----
> From: Stefan Sperling [mailto:st...@elego.de]
> Sent: Friday, May 10, 2013 08:41
> To: Andrew Reedick
> Cc: Branko Čibej; us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

> On Fri, May 10, 2013 at 10:20:54AM -0500, Andrew Reedick wrote:
> > It makes me wonder if it would make sense to slap a higher-level
> > interface on top of svn in order to implement the process aspects of
> > version control (and otherwise hide/keep the lower level
> > details/quirks away from users.)
>
> Yes, that makes sense.
>
> Subversion doesn't know anything about process. It only cares about
> version control. Process aspects are left to higher-level tools.

With a toolset like Subversion, having a simple, elegant design is key for many benefits.
There is definitely a trade-off between exposing the user interface at that level (basic operations add, cp, mv) versus exposing higher level concepts (branches, tags).

Providing only the lower level stuff gives more flexibility for people to use it creatively and do things that might not be possible with higher-level, but more rigid concepts.

Unfortunately, that also leaves us with having to define the higher level stuff ourselves. I support a big team (on the order of 150 engineers). They don't all have time to be svn experts, but to be productive team we all have to follow common conventions. I really miss not having branches and tags be first order objects.

Subversion is more like a toolset and you have to build your own machine. (Or as we say, it's a box of rope. You can do a lot with rope, but sometimes you hang yourself.)

As a version control tool, branches and tags seem like something that ought to be there, instead of merely conventions. But how I'd like to see there semantics work might be very different than other peoples'. So flexibility is a good thing.

-Steve

[Zé]

On 05/09/2013 09:35 PM, Branko Čibej wrote:
> The real problem here is that Subversion does not treat/renames/ as
> atomic operations.

I think that the real problem here is that Subversion doesn't support
branches. The fact is that moving or copying a file or directory around
is not the semantical equivalent of creating a branch. Therefore, if the
same operation is used to perform both then one will not be supported as
well as it could be.


Zé

[Zé]

On 05/10/2013 02:56 PM, Stefan Sperling wrote:
> It is strange behaviour on a conceptual level if you are used to
> thinking in terms of other version control systems (such as ClearCase
> in your case).
>
> However, it is a natural consequence of the way Subversion is currently
> supposed to represent the concepts of versioning files and directories,
> and labels and branches. And it has done so for over a decade. Changing
> this behaviour is far from trivial.
>
> I'm not entirely sure what kind of answer you are hoping to get.
> Are you happy with the answer that Subversion is simply not ClearCase?

You are misrepresenting the problem. It doesn't matter if subversion
isn't like any other SCM system. The problem is that the effect of
copying, renaming or moving a file or directory around, as done by any
SCM system, is incompatible with what's expected out of a development
branch. Using svn copy to structure a repo to simulate branches and
tags is a hack. The existence of a branch shouldn't depend on whether
someone checked out an older revision or not, and creating a branch
shouldn't appear on any file's history. Essentially the people behind
all popular SCM projects understood this right from the start.


Z�

[Branko Čibej]

I'll take the bait and ask you for the definition of the semantics of a
"branch".

-- Brane

[Thorsten Schöning]

Guten Tag Zé,
am Samstag, 11. Mai 2013 um 19:45 schrieben Sie:

> The existence of a branch shouldn't depend on whether
> someone checked out an older revision or not, and creating a branch
> shouldn't appear on any file's history. Essentially the people behind
> all popular SCM projects understood this right from the start.

I have a repo for binaries of one of our software which doesn't need
installation, which gets directly deployed to our customers. Each
customer is something like a branch or tag and some of the customers
are grouped for some reason, sharing the same parent directories,
share the same access rights etc. Some of my repos contain web
applications installed on different servers, again directly deployed
as working copies and again different installations on the same server
are grouped together under the same server name.

I have only little experience with git almost a year ago, but what I
remember is that git does support tags and branches and neither of
those could be structured in any way, git only allowed one level for
tags and branches. That's especially interesting because I've read a
lot of times that git is better with a large number of branches and
tags than Subversion, because branches and tags are easier to handle
in git.

And now please explain why it is better to be unable to structure
branches and tags in a way one likes or a project needs? And if git is
suboptimal in this case as well and other SCMs allow hierarchical
branches and tags, like Subversion, why should this hierarchy be
anything other or separate than what Subversion provides with its
files and directories?

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[Stefan Sperling]

On Sat, May 11, 2013 at 06:45:03PM +0100, Z� wrote:
> You are misrepresenting the problem. It doesn't matter if subversion
> isn't like any other SCM system. The problem is that the effect of
> copying, renaming or moving a file or directory around, as done by
> any SCM system, is incompatible with what's expected out of a
> development branch.

That's a matter of definition.

Recall that Subversion was designed to be better CVS. It was not
designed to be an SCM system that fits anyone's definition of what
an SCM system is and what kinds of abstractions it should support.

CVS had branches on a per-file level. That alone was deemed insuffient,
so Subversion also has branches on a per-directory level. It works well
enough this way for many use cases. But of course, it may not work for
every use case, and if so people should use a different tool.

[Zé]

On 05/11/2013 08:46 PM, Stefan Sperling wrote:
> On Sat, May 11, 2013 at 06:45:03PM +0100, Z� wrote:
>> You are misrepresenting the problem. It doesn't matter if subversion
>> isn't like any other SCM system. The problem is that the effect of
>> copying, renaming or moving a file or directory around, as done by
>> any SCM system, is incompatible with what's expected out of a
>> development branch.
>
> That's a matter of definition.

It isn't. It's pretty straight-forward. If copying directories around
ends up leaving traces on the revision history, which are forever stored
and forever made available in the repo's history, then resorting to this
hack to simulate branches goes against how developers expect a
development branch to work, and is a nuisance to those who have to
manage a repo and/or check its commit history.

> Recall that Subversion was designed to be better CVS. It was not
> designed to be an SCM system that fits anyone's definition of what
> an SCM system is and what kinds of abstractions it should support.

I don't believe any SCM is developed that way. They are, however,
designed to work properly. If creating a transient branch ends up being
eternally stored in a repo's commit history then branching method isn't
working properly.

> CVS had branches on a per-file level. That alone was deemed insuffient,
> so Subversion also has branches on a per-directory level.

No, it doesn't. It offers the ability to copy and move the trunk
directory around, and add that copy to the repository. That's not a
branch. That's a hack intended to make do with what features were
already available to try to simulate a branch.

> It works well
> enough this way for many use cases. But of course, it may not work for
> every use case, and if so people should use a different tool.

You're missing the point. The point is that subversion could be even
better than what it already is if it actually supported branches.


Z�

[Nico Kadel-Garcia]

And yet, somehow, it works.

This goes straight back to the origin of Subversion, as "CVS done
right". CVS had a *nightmarish* approach to handling tags and branches
and locking and secure remote access and a dozen other critical
features. It was used because it was very lightweight, easy to learn,
and let people shoot themselves in the foot if they really wanted to
for whatever reason.

Subversion developers ahve, understandably, elected not to enforce
tags/branching/trunk in the software, and let directory structure and
access management serve instead. This has provided enormous
flexibility: I can make a branch of only one small directory of a
trunk, and work with that, and merge it back without having to manage
a whole branch. And I can even weave them together in fascinating ways
with "svn:extern", to make new structures of multiple branches and
tags from multiple repositories.

As soon as you go to a more popular, mandated and hardcoded
"branch/trunk/tags" structure, you lose that flexibility and the
ability to have multiple small components of a repository tagged off
or branched off individually.

[Zé]

On 05/11/2013 08:25 PM, Thorsten Sch�ning wrote:
> I have a repo for binaries of one of our software which doesn't need
> installation, which gets directly deployed to our customers. Each
> customer is something like a branch or tag and some of the customers
> are grouped for some reason, sharing the same parent directories,
> share the same access rights etc.

That's not exactly a development branch, but a directory tree.
Subversion excels at versioning directory trees.

> Some of my repos contain web
> applications installed on different servers, again directly deployed
> as working copies and again different installations on the same server
> are grouped together under the same server name.
>
> I have only little experience with git almost a year ago, but what I
> remember is that git does support tags and branches and neither of
> those could be structured in any way, git only allowed one level for
> tags and branches.

Tags/branches aren't directories which need to be organized in a deep
hierarchical structure.

A branch, as implemented by git, is similar to the feature branches
approach mentioned in the manual, but properly supported by the SCM system.

http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns

Wit Git, when a branch is created it is expected to have a finite
lifespan, which is supposed to end either by being merged with the trunk
or being deleted, without leaving any trace on the versioning history.

A tag is nothing but a pointer to a particular point in the repo's history.

--
Z�

[Nico Kadel-Garcia]

On Sat, May 11, 2013 at 1:45 PM, Zé <jose....@gmx.com> wrote:

> You are misrepresenting the problem. It doesn't matter if subversion isn't
> like any other SCM system. The problem is that the effect of copying,
> renaming or moving a file or directory around, as done by any SCM system, is
> incompatible with what's expected out of a development branch. Using svn
> copy to structure a repo to simulate branches and tags is a hack. The
> existence of a branch shouldn't depend on whether someone checked out an
> older revision or not, and creating a branch shouldn't appear on any file's
> history. Essentially the people behind all popular SCM projects understood
> this right from the start.

Please let me refer you to the documentation for CVS, the ancestor of
Subversion:

http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_8.html#SEC35

There's log information, in the files of the branch, about its history
and status as a branch member. So the authors of CVS apparently
disagreed with your claim. It looks like you're interpreting a common
modern practice as fundamental to the nature of an SCM, and an aspect
so obvious it makes an SCM incorrect if the feature is not managed the
way you expect.

How many SCM's have you actually used extensively? From where do you
draw this conclusion?

[Thorsten Schöning]

Guten Tag Zé,
am Samstag, 11. Mai 2013 um 23:26 schrieben Sie:

> That's not exactly a development branch, but a directory tree.

That's simply a matter of taste and what I said for customer/server
related hierarchies of tags fits perfectly well for branches which
develop towards e.g. one bigger feature.

> Tags/branches aren't directories which need to be organized in a deep
> hierarchical structure.

That's your opinion but as you said before it's "not the point". The
point is that git is not capable of doing things the way I like and
Subversion not the way that you like.

> Wit Git, when a branch is created it is expected to have a finite
> lifespan, which is supposed to end either by being merged with the trunk
> or being deleted, without leaving any trace on the versioning history.

And what about tags for nightly builds etc.?

> A tag is nothing but a pointer to a particular point in the repo's history.

Which ignores the important thing that the user should be able to
organize those points the way he likes. Or what's exactly what you are
criticizing on Subversion?

[Stefan Sperling]

On Sat, May 11, 2013 at 10:50:12PM +0100, Z� wrote:
> You're missing the point. The point is that subversion could be
> even better than what it already is if it actually supported
> branches.

OK, I would also like Subversion to get better, so we agree here.

Now, what kinds of improvements would you hope to gain from adding
a first-class concept called "branch" to the current system?

Keep in mind that adding a new dimension to the current repository
data model is a huge amount of work. We need a design spec that is
solid, and we need to have a very good idea of how to implement
that design, using the current system as a starting point.

We need to know how all existing operations will be affected by the
extended data model, and how they need to behave in the new data model.
We need to define use cases and test cases for any new behaviour.

We need to know if and how these changes affect our two network
communication protocols, and perhaps implement changes there.

And it also needs to be backwards compatible all the way back to SVN 1.0.

If the only result of this humongous effort is fixing a problem of an
arguably cosmetic nature, such as copies/moves of directories no longer
reflecting on the history of their children, then I'm not very convinced
that changing the data model is worth it.

But if it can fix some of the sore points of Subversion, in particular
better support for merging of renames and resolving tree conflicts,
then I'm all ears and would like to learn more about your ideas.

We are trying to fix several of Subversion's sore points within the
current data model, and it is getting increasingly hard. However, so
far I haven't seen a very convincing reason to make exhaustive changes
to the repository backend. I've experimented with making enhancements
to the backend on a smaller scale than you are proposing
(http://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/BRANCH-README)
or not making any backend changes at all but having the client do more work
(http://svn.apache.org/repos/asf/subversion/branches/moves-scan-log/BRANCH-README)
But those ideas didn't get us anywhere yet.

I know that some disagree with me about whether we need to make
exhaustive changes to the backend, see http://wiki.apache.org/subversion/FS2
But so far nothing has materialised from that. Perhaps we'll start
seeing some results from those ideas, perhaps not. I don't know.
The page still says that "There is currently no implementation plan."

[Bob Archer]

> On Sat, May 11, 2013 at 10:50:12PM +0100, Zé wrote:
> > You're missing the point. The point is that subversion could be even
> > better than what it already is if it actually supported branches.
>
> OK, I would also like Subversion to get better, so we agree here.
>
> Now, what kinds of improvements would you hope to gain from adding a first-
> class concept called "branch" to the current system?
>
> Keep in mind that adding a new dimension to the current repository data model
> is a huge amount of work. We need a design spec that is solid, and we need to
> have a very good idea of how to implement that design, using the current
> system as a starting point.
>
> We need to know how all existing operations will be affected by the extended
> data model, and how they need to behave in the new data model.
> We need to define use cases and test cases for any new behaviour.
>
> We need to know if and how these changes affect our two network
> communication protocols, and perhaps implement changes there.
>
> And it also needs to be backwards compatible all the way back to SVN 1.0.

That is only true if this change is 1.something. But, if it is 2.0 then the svn rules allow for a break in backward compatibility.

What I don't understand is why someone argues about how git does something is better yet uses svn. Use the tool that works for you, or works the way you expect a tool to work.

BOb

[C. Michael Pilato]

On 05/13/2013 10:04 AM, Bob Archer wrote:
> What I don't understand is why someone argues about how git does
> something is better yet uses svn. Use the tool that works for you, or
> works the way you expect a tool to work.

Oh, I'm sure if we tried we could all think up plenty of reasons why someone
might argue the superiority of one tool over another and yet use "the
other". Perhaps the superiority isn't universal -- only some features are
better, while some lack. Perhaps the choice of tool isn't available for one
reason or another. Whatever. It hardly matters here -- on this list -- why
someone who likes Git also uses Subversion.

What matters is the desired outcome of the discussion. This list is about
Subversion. OtherVCSystem fanboyism isn't welcome here, not because it's
fanboyism (which is just intellectually pathetic) but because it's
off-topic. But merely pointing out things that Git does better (in
someone's approximation) than Subversion isn't necessarily fanboyism. And
if the point of comparing Subversion to Git or Hg or OtherVCSystem is to
find ways to make Subversion a better product, that's completely on-topic
and welcome (so long as the discussion is handled maturely).

--
C. Michael Pilato <cmpi...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development

[Les Mikesell]

On Mon, May 13, 2013 at 9:04 AM, Bob Archer <Bob.A...@amsi.com> wrote:
>
> What I don't understand is why someone argues about how git does something is better yet uses svn. Use the tool that works for you, or works the way you expect a tool to work.

Or, learn what to expect from the tool you use... If I followed the
thread correctly, the 'problem' involved was not expecting subversion
to consider a directory rename as a change to everything below. If
you know that subversion doesn't know/care about the location of what
you think of as the 'project', you could simply position it so that
you wouldn't need to rename the directories above the branches. Or at
least not be surprised when subversion sees that as a change.

--
Les Mikesell
lesmi...@gmail.com

[Bob Archer]

Yes, I get what you are saying. But, to claim the way svn supports branches and tags is a "hack" doesn't seem like a productive conversation. It is far from a hack and that statement dismisses all the hard work of design and implementation that went into svn almost dismissing the whole team many of which are volunteers.

It would be nice if branches could become a first class object with the branch command being very specific. But, what we have is far from a hack if you understand how it works.

I would like to see more "first class" support for projects and/or defining a project root. For example, perhaps there can be an svn:projectroot property that must be on a folder and the branch/merge command will only work on project roots. If that is done of course the maintain backward compatibility there could be a switch in the client config to allow for bypassing this requirement, or perhaps the --force switch could do it. Also, a property can be place on a branch so that tooling can know it is actually a semantic branch rather than just a fork (copy).

[Stefan Sperling]

On Mon, May 13, 2013 at 03:21:15PM +0000, Bob Archer wrote:
> I would like to see more "first class" support for projects and/or
> defining a project root. For example, perhaps there can be an
> svn:projectroot property that must be on a folder and the branch/merge
> command will only work on project roots. If that is done of course the
> maintain backward compatibility there could be a switch in the client
> config to allow for bypassing this requirement, or perhaps the --force
> switch could do it. Also, a property can be place on a branch so that
> tooling can know it is actually a semantic branch rather than just a
> fork (copy).

This idea has been discussed before and could still be viable in
the future.

Some references to start browsing:
http://svn.haxx.se/dev/archive-2009-09/0156.shtml
http://svn.haxx.se/dev/archive-2011-10/0065.shtml

[Les Mikesell]

On Mon, May 13, 2013 at 10:37 AM, Stefan Sperling <st...@elego.de> wrote:
>
>> I would like to see more "first class" support for projects and/or
>> defining a project root. For example, perhaps there can be an
>> svn:projectroot property that must be on a folder and the branch/merge
>> command will only work on project roots. If that is done of course the
>> maintain backward compatibility there could be a switch in the client
>> config to allow for bypassing this requirement, or perhaps the --force
>> switch could do it. Also, a property can be place on a branch so that
>> tooling can know it is actually a semantic branch rather than just a
>> fork (copy).
>
> This idea has been discussed before and could still be viable in
> the future.

Maybe it is just my misconception, but I've always thought of the
difference between svn and git as being that svn conceptually tracks
complete revisions although sometimes it might generate or store
differences for some operations or internal storage convenience, where
git tracks changesets although it often has to generate complete
revisions. The nature of branches seems to relate better to
changesets since you are likely to want to merge/apply the same
changesets to different places - but, if you track the changesets you
have to anchor those changes to the tree that was the base for the
changes.

--
Les Mikesell
lesmi...@gmail.com

[Andreas Krey]

On Mon, 13 May 2013 11:32:13 +0000, Les Mikesell wrote:
...

> Maybe it is just my misconception, but I've always thought of the
> difference between svn and git as being that svn conceptually tracks
> complete revisions although sometimes it might generate or store
> differences for some operations or internal storage convenience, where
> git tracks changesets although it often has to generate complete
> revisions.

That indeed is just a misconception. git even goes to define exactly
how each commit (aka revision) is stored including its checksum.
This even though is it then going to internally store that in
a dense packfile format.

> The nature of branches seems to relate better to

No, the basic difference is that VCS operating on the whole tree can
only have branches (and thus merge info) on the whole tree either, so
you *can't* go like subversion does and map branches into the tree and
need to have them (and tags) as a separate concept.

SVN, instead of having branches as a separate concept, also stores whole
trees, but instead additionally stores 'this came from there' or 'that
was merged here' as a separate concept.

Andreas

--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[Les Mikesell]

On Mon, May 13, 2013 at 12:23 PM, Andreas Krey <a.k...@gmx.de> wrote:
> On Mon, 13 May 2013 11:32:13 +0000, Les Mikesell wrote:
> ...
>> Maybe it is just my misconception, but I've always thought of the
>> difference between svn and git as being that svn conceptually tracks
>> complete revisions although sometimes it might generate or store
>> differences for some operations or internal storage convenience, where
>> git tracks changesets although it often has to generate complete
>> revisions.
>
> That indeed is just a misconception. git even goes to define exactly
> how each commit (aka revision) is stored including its checksum.
> This even though is it then going to internally store that in
> a dense packfile format.

What it computes internally or uses as an internal storage isn't quite
the point. Svn would also always compute the differences even though
it really only cares about the full revisions. What does git do if
you try to double-merge a change? Does it know about the previous
merge by its changeset commit id, look at the contents that are
already present, or just do it twice?

>> The nature of branches seems to relate better to
>
> No, the basic difference is that VCS operating on the whole tree can
> only have branches (and thus merge info) on the whole tree either, so
> you *can't* go like subversion does and map branches into the tree and
> need to have them (and tags) as a separate concept.

I can see why it might be a problem to support concurrent nested
branch changeset roots but that scenario is problematic any way you
look at it. Why would it be a problem to support parallel branching
roots - perhaps with some enforcement on the source/dest top levels
having some common parent?

> SVN, instead of having branches as a separate concept, also stores whole
> trees, but instead additionally stores 'this came from there' or 'that
> was merged here' as a separate concept.

But does 'that was merged here', really know about the commit
changeset where the change originated?

--
Les Mikesell
lesmi...@gmail.com

[Bob Archer]

> On Mon, May 13, 2013 at 12:23 PM, Andreas Krey <a.k...@gmx.de> wrote:
> > On Mon, 13 May 2013 11:32:13 +0000, Les Mikesell wrote:
> > ...
> >> Maybe it is just my misconception, but I've always thought of the
> >> difference between svn and git as being that svn conceptually tracks
> >> complete revisions although sometimes it might generate or store
> >> differences for some operations or internal storage convenience,
> >> where git tracks changesets although it often has to generate
> >> complete revisions.
> >
> > That indeed is just a misconception. git even goes to define exactly
> > how each commit (aka revision) is stored including its checksum.
> > This even though is it then going to internally store that in a dense
> > packfile format.
>
> What it computes internally or uses as an internal storage isn't quite the point.
> Svn would also always compute the differences even though
> it really only cares about the full revisions. What does git do if
> you try to double-merge a change? Does it know about the previous merge by
> its changeset commit id, look at the contents that are already present, or just
> do it twice?

Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge.

That said, I don't even think you can specify in git "what" to merge it just merges all the changes. I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target.

BOb

[Andreas Krey]

On Mon, 13 May 2013 13:29:39 +0000, Les Mikesell wrote:
...

> ... What does git do if

> you try to double-merge a change?

You can't.

> Does it know about the previous
> merge by its changeset commit id, look at the contents that are
> already present, or just do it twice?

It doesn't have a notion like "this changeset is merged, that
one isn't, this is again", like in the 3-10,12-14 in the mergeinfo.

Each commit has a parent (or two in the case or a merge commit), and
it just computes the latest common commit and takes that as the
base for a 3-way-merge between the two branches in question.
(Ok, the merge base computation isn't that easy in more complicated
DAGs, but anyway.) If you merge again the end of the source branch
at previous merge time is the new merge base. Merge base computation
is what CVS utterly failed, and SVN for a long time being the better
CVS repeated that.

...

> I can see why it might be a problem to support concurrent nested
> branch changeset roots but that scenario is problematic any way you
> look at it. Why would it be a problem to support parallel branching
> roots - perhaps with some enforcement on the source/dest top levels
> having some common parent?

I don't think I will understand this paragraph without more
terminology definition or examples.

> > SVN, instead of having branches as a separate concept, also stores whole
> > trees, but instead additionally stores 'this came from there' or 'that
> > was merged here' as a separate concept.
>
> But does 'that was merged here', really know about the commit
> changeset where the change originated?

Only in the summarily way that it knows when a branch was merged
into another. Everything that is reachable through the commit
parent relation is 'merged in'. You can't selectively
merge specific comments (and record that). You only have
'merge arrows' that tell when everything of a branch was
merged into another, no lists of commits that got merged
(and that make merge algos take forever).

[Andreas Krey]

On Mon, 13 May 2013 18:35:35 +0000, Bob Archer wrote:
...

> Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge.
> That said, I don't even think you can specify in git "what" to merge it just merges all the changes.

Right; there is no list of commits that got merged, but only a second
parent pointer in the merge commit that points to the (then) head of
the branch.

> I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target.

Yes, except that it actually does a three-way merge with the current
branch head and the cherry-picked commit as the ends and the parent of
the cherry-pick commit as the base - this is more robust than applying
a patch.

[Zé]

On 05/13/2013 03:04 PM, Bob Archer wrote:
> What I don't understand is why someone argues about how git does
> something is better yet uses svn. Use the tool that works for you, or
> works the way you expect a tool to work.

If you think my comments were about Git then you missed the point
entirely. In fact, it doesn't even make any sense to single out Git,
because Git isn't the only SCM system out there that actually supports
branching.

Regarding your comment about using the tool that works for you, it
really only applies to hobbyists who work alone on their pet projects
and are free to make any decision regarding any change to how they've
organized it. When someone is a member of a team that is organized
around a particular SCM system then that ceases to be a valid
assumption. Nevertheless, I fail to see how that has any relevance
regarding the way Subversion would be better if it supported branching.


--
Z�

[Zé]

On 05/13/2013 04:21 PM, Bob Archer wrote:
> Yes, I get what you are saying. But, to claim the way svn supports
> branches and tags is a "hack" doesn't seem like a productive
> conversation. It is far from a hack and that statement dismisses all
> the hard work of design and implementation that went into svn almost
> dismissing the whole team many of which are volunteers.
>
> It would be nice if branches could become a first class object with
> the branch command being very specific. But, what we have is far from
> a hack if you understand how it works.
>
> I would like to see more "first class" support for projects and/or
> defining a project root. For example, perhaps there can be an
> svn:projectroot property that must be on a folder and the
> branch/merge command will only work on project roots. If that is done
> of course the maintain backward compatibility there could be a switch
> in the client config to allow for bypassing this requirement, or
> perhaps the --force switch could do it. Also, a property can be place
> on a branch so that tooling can know it is actually a semantic branch
> rather than just a fork (copy).
>
>

No one is dismissing anyone's work. Quite the contrary. I don't know
where you managed to get that idea. What has been said regarding
subversions lack of support for branching was, I think, quite clear.
You may prefer using euphemisms such as "first class support" to refer
to the actual support for branches, and in the process actually agree
with what has been said about subversion and branches, but that doesn't
mean that referring to the same issue through different names implies
that anyone is dismissing anyone's work.

--
Zé

[Nico Kadel-Garcia]

On Tue, May 14, 2013 at 4:33 PM, Zé <jose....@gmx.com> wrote:
>
> No one is dismissing anyone's work. Quite the contrary. I don't know

I'm afriad you did, with the insistence that branching *in the form
you expect* is a given in all SCM's, and that Subversion is therefore
clearly missing a very critical and quite necessary feature. It's a
common behavior, true, but if you look at Subversion's ancestor CVS
you see that it did not exist, either, in that clean but restrictive
layout. I've also pointed out to you that the top repository root
based branching, if built integrally into the software, makes the
branching or tagging of subdirectories very difficult. It can actively
interfere with the workflow of quite a few people who pop small,
related tools into branches to test them and who may never attempt to
integrate them into the trunk.

I'm not saying it's the best approach, but the flexibility of the
purely directory based and not software based workflow can be useful.

> where you managed to get that idea. What has been said regarding
> subversions lack of support for branching was, I think, quite clear. You may

Yes, it has been quite clear that you've chosen to redefine branching
as something that is derived from particular software features, rather
than actual workflow. Please, go look up branching: the Wikipedia
entry for "Branching (revision control)" is pretty good, and says
*nothing* about the kind of additional constraints you are insisting
are inherent to branching. It's as if someone wrote the definition
based on how people actually use the word!

[Les Mikesell]

On Tue, May 14, 2013 at 3:33 PM, Zé <jose....@gmx.com> wrote:
>>
> What has been said regarding
> subversions lack of support for branching was, I think, quite clear.

Well, no. The only thing you've made clear is that you don't like it
or you don't understand how it is supposed to be used. You have not
explained why you lay your projects out so that you need to move the
parent directories of your project around after creating branches.
Nor have you made any real suggestions about how it might be improved
in a way that doesn't break the ability to copy and subsequently merge
any arbitrary subdirectory which is clearly a feature even though it
doesn't mesh well with your concept of only having one way to branch.

--
Les Mikesell
lesmi...@gmail.com

[Andrew Reedick]

Isolating change is a fundamental tenet behind branching. The fact that an "outside" change can affect a branch (and a tagged baseline) is wrong by definition.

Telling folks to never change their branching structure is a bit short-sighted given the lack of reliable precognitive ability in general and that occasionally folks like to clean up the branches and tags dir when they're cluttered with dozens of old branches and tags. Telling folks not to run 'svn mv tags/1.0* archive/' simply isn't helpful. Plus, telling people not use to svn's touted directory manipulation features because of side-effects is a bit self-defeating.


As for the various CVS comments in the thread, no one cares if Subversion was originally meant to be a better CVS. Building a better CVS is akin to saying "let's build a better Model-T". Personally, when it was announced that svn wouldn't include merge tracking, I wrote off SVN as useless for not including the basics. Fortunately, merge-tracking and merging have come a long way since then and I, for one, am looking forward to 1.8 driving a stake in --reintegrate.

Furthermore, Subversion's vision statement is:
"Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations."

In the Future(tm), Subversion, IMHO, will need to treat branches (and tags) as first class objects because branches and tags are core concepts of modern version control systems. To re-emphasize my point, isolated branches are an expected, fundamental, expected, and/or part of a minimal set of features that any VCS must support. So please, no more references to "svn being a better CVS". It's a very limiting and short-sighted thing to say.


Fortunately, the "parent dir changes affect branch history" problem is a minor hiccup. There's no need to grab torches and pitchforks and rush to implement formal branches right now. It's just something that needs to be kept in the back of people's minds once the merging, tree merging, and true renames are implemented and are mature. I think that most folks can live with a spurious revision appearing in 'svn log' entry after a parent dir change.

[Les Mikesell]

On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>
>
> Isolating change is a fundamental tenet behind branching. The fact that an "outside" change can affect a branch (and a tagged baseline) is wrong by definition.
>

OK, but that means you need to anchor the concept of 'this branch' to
the top of the tree that you consider isolated. There is no such
concept now.

> Telling folks to never change their branching structure is a bit short-sighted given the lack of reliable precognitive ability in general and that occasionally folks like to clean up the branches and tags dir when they're cluttered with dozens of old branches and tags. Telling folks not to run 'svn mv tags/1.0* archive/' simply isn't helpful.

So, do you want to disallow such moves - or make merge tracking aware
of all the possibilities in the repository tree?

> Plus, telling people not use to svn's touted directory manipulation features because of side-effects is a bit self-defeating.

Not if you want it to act like SCM's that have branches that don't
allow such things.

--
Les Mikesell
lesmi...@gmail.com

[Andreas Krey]

On Wed, 15 May 2013 13:06:52 +0000, Andrew Reedick wrote:
...

> In the Future(tm), Subversion, IMHO, will need to treat branches (and tags) as first class objects because branches and tags are core concepts of modern version control systems.

So what? SVN decided to map them into the directory structure.[1]
If it ever doesn't anymore, it won't be SVN anymore.

Andreas

[1] Whether that is a good decision is an orthogonal question.
I don't think it was.

[Branko Čibej]

On 15.05.2013 19:06, Andrew Reedick wrote:
> Isolating change is a fundamental tenet behind branching. The fact that an "outside" change can affect a branch (and a tagged baseline) is wrong by definition.

I suspect this discussion has strayed somewhat from the mandate of this
list ... so let me try to wrap it up.

The kind of branch semantics that you propose can be achieved in
Subversion by using the top-level directory of a repository as the root
of all branches. Subversion could "easily" do this in some future
(backward-incompatible) version by, e.g., simply hiding that root level
and calling it the branch namespace. However, that would not in any way
simplify the task of tracking file-level cherry-picks or partial merges
(both of which, I'll take the liberty to point out, git tends to ignore).

I agree it would be nice if Subversion had first-class branches from day
one, and settled for a far simpler object model; at least we wouldn't be
in the situation where it's possible to have two branches of the same
file in the same directory (which makes the merge tracking problem an
order of magnitude harder).

On the other hand, it would hardly be a service to our users if we
drastically broke backwards compatibility by fundamentally changing the
object model; regardless of anyone's opinion about the decisions that
lead to it being the way it is. Instead, we're working within the
constraints of that model with the goal to address many -- but obviously
not all -- of the concerns raised in this thread.

And a final note: Subversion is not intended to be the ideal tool for
every situation, and never will be. If Subversion's features cannot
support your workflow, there are only two solutions: change the
workflow, or replace Subversion. Both are valid decisions, and neither
is trivial.

-- Brane

--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

[Zé]

On 05/13/2013 06:23 PM, Andreas Krey wrote:
> No, the basic difference is that VCS operating on the whole tree can
> only have branches (and thus merge info) on the whole tree either, so

> you*can't* go like subversion does and map branches into the tree and

> need to have them (and tags) as a separate concept.

Compared to how other SCM systems handle tags, subversion also doesn't
have tags as a separate concept. Subversion provides a way to pinpoint
each commit objectively and unambiguously by specifying specific
revisions. The only difference between subversion and other SCM systems
is that other systems offer support for labeling and adding useful info
to those revisions, while Subversion doesn't.

If you are referring to the ad-hoc method of copying the trunk/branch to
a subdirectory then all that you're doing is copying the trunk directory
to another directory in your repository. That may be a convenient hack,
but that isn't exactly support for tagging.

Let's put it this way: if that was actually a tag then it could also be
argued that any file system supports branching/tagging.

--
Z�

[Zé]

On 05/15/2013 04:04 PM, Les Mikesell wrote:

> On Tue, May 14, 2013 at 3:33 PM, Z� <jose....@gmx.com> wrote:
>>>
>> What has been said regarding
>> subversions lack of support for branching was, I think, quite clear.
>
> Well, no. The only thing you've made clear is that you don't like it
> or you don't understand how it is supposed to be used.

Read what I've wrote. Stick to what I've actually said, and don't put
words in other people's mouths.

> You have not
> explained why you lay your projects out so that you need to move the
> parent directories of your project around after creating branches.

You either failed to understand what has been written or you're
imagining claims. Please quote exactly where I made such a claim.

> Nor have you made any real suggestions about how it might be improved

I've already did. I've suggested that it would be great if subversion
supported branching. People already replied to this thread saying that
that feature is currently on the back burner.

Next time try not to be rude and do read the posts you're replying to.


Z�

[Zé]

Don't you understand that *that's precisely the problem*? Currently,
subversion does not support branching, and it's only possible to
manipulate subversion to *act* like it does by copying around
subdirectories in the repository, and in the process screw up with the
repo's revision history.


--
Z�

[Thorsten Schöning]

Guten Tag Zé,
am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:

> The only difference between subversion and other SCM systems
> is that other systems offer support for labeling and adding useful info
> to those revisions, while Subversion doesn't.

Which useful info besides the name, and always present things like a
revision, timestamps, who made the commit etc. is this? And how does
one benefit of those additional info compared to the lack of
structuring of branches and tags those SCMs provide compared to
Subversion?

> If you are referring to the ad-hoc method of copying the trunk/branch to
> a subdirectory then all that you're doing is copying the trunk directory
> to another directory in your repository. That may be a convenient hack,
> but that isn't exactly support for tagging.

That's not an argument at all, because all one does in other SCMs is
creating branches and tags. What you really should argue is what all
devs think is common sense about branches and tags and why Subversion
doesn't fulfill those requirements. The only thing mentioned until
now is that revision numbers can change in the way subversion handles
branches and tags and that only because Subversion does provide
features, like (re)structuring branches and tags in a hierarchical
way, other SCMs simply doesn't provide.

> Let's put it this way: if that was actually a tag then it could also be
> argued that any file system supports branching/tagging.

You ignore the versioning part of Subversion and that it guarantees
the state/history of branches and tags like any other SCM. Besides
that, from my understanding filesystems do provide something which
could be argued as support for branches and tags because branches are
simply just work on something based on something other, which is
implemented as copying files and directories, and tags are something
which isn't as worked on as on branches, but is based on something
other, too, and may easily be implemented using copying things around
again and simply don't touch it anymore or e.g. using snapshots, which
would better guarantee an unchanged content.

Filesystems with snapshots for tags would again provide benefits over
SMCs like git and their branching and tagging facilities because the
user has more flexibility in organizing his contents.

[David Chapman]

You are pretty insistent that there is One True Way to use branches in
development. A lot of people do not agree with you. I've seen branches
used as long-term development vehicles (think years), with only
cherry-picked merges coming in from or going back to trunk. This does
not match the definition of "use once and discard" that you are
promulgating.

Subversion was designed as a versioned file system, in response to the
shortcomings of CVS; concepts like branching and tagging have always
been naming conventions built on top of that (later, merge tracking was
added to assist branching). If you go back and look at the archives of
this list, you will see this quite clearly. "trunk", "branches", and
"tags" are simply naming conventions. People don't even need to follow
those, as has been noted time and again. This gives people a lot of
flexibility, which they quite naturally use.

And yes, ordinary file systems do support branching and tagging. I've
seen it done. It's expensive, but it works.

If you want Subversion to be extended in a particular way, learn its
internals and write a spec which comprehends the internals and current
usage. Maybe then someone will be inclined to work on it. Better yet,
offer help. This is a community project, after all, and what better way
to be a member of the community than to help? Right now you are not.

--
David Chapman dcch...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

[Zé]

On 05/18/2013 06:33 PM, Thorsten Sch�ning wrote:
> Guten Tag Z�,

> am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
>
>> The only difference between subversion and other SCM systems
>> is that other systems offer support for labeling and adding useful info
>> to those revisions, while Subversion doesn't.
>
> Which useful info besides the name, and always present things like a
> revision, timestamps, who made the commit etc. is this? And how does
> one benefit of those additional info compared to the lack of
> structuring of branches and tags those SCMs provide compared to
> Subversion?

Subversion doesn't offer tags explicitly. The closest it has is revision
numbers, and the standard course of action is to simulate this feature
by creating a dedicated subdirectory that is used exclusively to store
copies of the trunk whose names are selected to reflect tags.

Having said that, the "let's copy the trunk to a subdirectory" approach
to simulate tags is not a problem, nor is it a shortcoming. People have
emulated tags by storing tar files containing copies of the trunk, and
that works well.

>> If you are referring to the ad-hoc method of copying the trunk/branch to
>> a subdirectory then all that you're doing is copying the trunk directory
>> to another directory in your repository. That may be a convenient hack,
>> but that isn't exactly support for tagging.
>
> That's not an argument at all, because all one does in other SCMs is
> creating branches and tags. What you really should argue is what all
> devs think is common sense about branches and tags and why Subversion
> doesn't fulfill those requirements.

That has already been repeatedly stated. Again, using the ad-hoc
directory copy/move operations to simulate branches stores all the
changes in the repo's revision history for all eternity, even when
creating short-lived development branches which don't go anywhere and
end up being deleted.

> The only thing mentioned until
> now is that revision numbers can change in the way subversion handles
> branches and tags and that only because Subversion does provide
> features, like (re)structuring branches and tags in a hierarchical
> way, other SCMs simply doesn't provide.

That's the least of anyone's concern. The issue is that behind those
revision numbers there are real changes made to the repository, which
are eternally kept there and are made available to anyone. If you create
a directory, change some files and delete the directory, and each
operation is individually committed to the repository, each of those
operations are eternally made available in the repository. This means
you can checkout a specific revision that presents you with any of those
changes. If you resort to those operations to emulate development
branches, which is the only way that subversion is able to emulate them,
then you end up storing in your repository revisions that reflect
dead-ends which didn't made their way into the trunk, and those
revisions do have an influence in subsequent revisions committed to the
repository.

>> Let's put it this way: if that was actually a tag then it could also be
>> argued that any file system supports branching/tagging.
>
> You ignore the versioning part of Subversion and that it guarantees
> the state/history of branches and tags like any other SCM.

You've missed the point. The point was that the suggested ad-hoc way to
emulate tags with subversion is to copy a snapshot of the trunk to a
subdirectory. That doesn't mean that a file system supports tags.

> Besides
> that, from my understanding filesystems do provide something which
> could be argued as support for branches and tags because branches are
> simply just work on something based on something other, which is
> implemented as copying files and directories, and tags are something
> which isn't as worked on as on branches, but is based on something
> other, too, and may easily be implemented using copying things around
> again and simply don't touch it anymore or e.g. using snapshots, which
> would better guarantee an unchanged content.

That's essentially what subversion does, as the only thing it actually
does is track revisions made in a specific directory. It works very
well for a wide range of applications, in some cases better than other
SCM systems, but the lack of support for branches does represent a a
shortcoming.


Z�

[Daniel Shahaf]

On Sat, May 18, 2013 at 07:33:10PM +0200, Thorsten Sch�ning wrote:
> ...

> > Let's put it this way: if that was actually a tag then it could also be
> > argued that any file system supports branching/tagging.
>
> You ignore the versioning part of Subversion and that it guarantees
> the state/history of branches and tags like any other SCM. Besides
> that, from my understanding filesystems do provide something which
> could be argued as support for branches and tags because branches are
> simply just work on something based on something other, which is
> implemented as copying files and directories,

Some filesystems support branching/tagging as a first order operation: e.g.,
with zfs you have 'zfs snapshot' for immutable tags and 'zfs clone' for (shared
storage, copy on write) tags.

http://man.freebsd.org/zfs

[Zé]

On 05/18/2013 07:16 PM, David Chapman wrote:
>
> You are pretty insistent that there is One True Way to use branches in
> development.

No, I'm stating that if all a SCM does is track changes made to the
contents of a directory and you rely on changes made to that directory
to emulate branches, then there are some significant downsides to this
approach when compared with SCM systems which do offer support for
branching.

> A lot of people do not agree with you. I've seen branches
> used as long-term development vehicles (think years), with only
> cherry-picked merges coming in from or going back to trunk. This does
> not match the definition of "use once and discard" that you are
> promulgating.

You've missed the point. It's irrelevant if some development branches
last for ages. The point is that when a SCM system does support
branching, it doesn't matter if you organize your workflow based on
development branches that last for ages or are only transient, because
that SCM system does offer support for both of those approaches. With
subversion, as it doesn't support branching, then you are only able to
simulate them by making copies of the trunk and moving them around your
repository, and although that approach doesn't cause any major problems
if all your branches will be eternally worked on, it becomes a problem
with transient branches such as those which are used in the feature
branches approach.

> Subversion was designed as a versioned file system, in response to the
> shortcomings of CVS; concepts like branching and tagging have always
> been naming conventions built on top of that (later, merge tracking was
> added to assist branching). If you go back and look at the archives of
> this list, you will see this quite clearly. "trunk", "branches", and
> "tags" are simply naming conventions.

I've been saying that from the start, and I've received some unfortunate
replies for doing so.

> People don't even need to follow
> those, as has been noted time and again. This gives people a lot of
> flexibility, which they quite naturally use.

That isn't being disputed. What has been stated, and stated repeatedly,
is that it would be even better if subversion actually offered support
for branches.

> And yes, ordinary file systems do support branching and tagging. I've
> seen it done. It's expensive, but it works.
>
> If you want Subversion to be extended in a particular way, learn its
> internals and write a spec which comprehends the internals and current
> usage. Maybe then someone will be inclined to work on it. Better yet,
> offer help. This is a community project, after all, and what better way
> to be a member of the community than to help? Right now you are not.

As you may understand, not everyone has a lot of time to spend on side
projects, and when they do then there's the problem of attaining the
insight and technical know-how to do so.

In spite of that, I don't believe that not being able to spend time
contributing to a project justifies declaring a specific suggestion to
be tabu. Forbidding anyone from, or attacking them for mentioning a
downside or a shortcoming doesn't make it go away, and doesn't make the
project any better than what it already is. What does contribute to its
improvement is providing suggestions on ways to improve it, such as
suggesting that implementing a sorely missed feature would be a
significant improvement. Do you agree?

--
Z�

[David Chapman]

On 5/18/2013 12:01 PM, Z� wrote:
> On 05/18/2013 07:16 PM, David Chapman wrote:
>>
>> You are pretty insistent that there is One True Way to use branches in
>> development.
>
> No, I'm stating that if all a SCM does is track changes made to the
> contents of a directory and you rely on changes made to that directory
> to emulate branches, then there are some significant downsides to this
> approach when compared with SCM systems which do offer support for
> branching.

You've missed the point. You have a specific definition of branching
and do not believe that anything else can be called branching. In your
message to Thorsten Sch�ning, you said that branch history should be
deleted if the branch is deleted. That is fundamentally in opposition
to the definition of Subversion, which is meant to retain all of a
project's history. People ask for an "obliterate" feature all the time
after committing a file with private information, e.g. passwords. That
is hard by design within Subversion, and most of its users are glad. I,
for one, would object strenuously if the history of a branch were
deleted just because it was never merged into trunk. In my business
(Electronic Design Automation), knowing what doesn't work (and why) is
often just as important as knowing what does work.

>
> As you may understand, not everyone has a lot of time to spend on side
> projects, and when they do then there's the problem of attaining the
> insight and technical know-how to do so.
>
> In spite of that, I don't believe that not being able to spend time
> contributing to a project justifies declaring a specific suggestion to
> be tabu. Forbidding anyone from, or attacking them for mentioning a
> downside or a shortcoming doesn't make it go away, and doesn't make
> the project any better than what it already is. What does contribute
> to its improvement is providing suggestions on ways to improve it,
> such as suggesting that implementing a sorely missed feature would be
> a significant improvement. Do you agree?
>

As I said, you have a specific definition of branching and are insisting
that it is the only valid definition even though it would require a
fundamental revision of Subversion's data model. You are insisting that
branching be implemented your way even though others disagree. This is
not helpful.

Saying "+1 for branches as a first class object" is helpful because it
allows developers to prioritize their donated time, and to choose a
definition and implementation that balance features vs. implementation
complexity. But unless you are willing to dig into the internals of
Subversion and understand how it is used, insisting on a particular
definition and implementation is not helpful.

[Johan Corveleyn]

On Sat, May 18, 2013 at 9:33 PM, David Chapman <dcch...@acm.org> wrote:

> On 5/18/2013 12:01 PM, Zé wrote:
>>
>> On 05/18/2013 07:16 PM, David Chapman wrote:
>>>
>>>
>>> You are pretty insistent that there is One True Way to use branches in
>>> development.
>>
>>
>> No, I'm stating that if all a SCM does is track changes made to the
>> contents of a directory and you rely on changes made to that directory to
>> emulate branches, then there are some significant downsides to this approach
>> when compared with SCM systems which do offer support for branching.
>
>
> You've missed the point. You have a specific definition of branching and do
> not believe that anything else can be called branching. In your message to

> Thorsten Schöning, you said that branch history should be deleted if the

Let's take a step back. What was the actual problem that lead to this
discussion?

Zé, I fully agree that suggesting ways for improvement, and generally
participating in discussions with users and devs, are very valuable
ways of contributing. In fact, participating in the mailing lists is
the first item mentioned on the "Getting involved" page [1].

However, this discussion lacks focus, it sounds more like a
philosophical debate, with large ideas being thrown against each
other. If you want to get anything useful out of this discussion (be
it planting the seeds for improvements to Subversion, or be it a
deeper understanding for yourself of how to work effectively with
svn), you'll have to get much more concrete.

So what's the actual problem (or problems) with SVN's branching and
tagging? Where does it hurt your workflow? What would make SVN not
"hurt you" in that way?

Please be concrete, and give examples of what really bothers you as a
user or an admin in your daily work. Saying that "branches are not
first class", or "I don't like it that Subversion implements
branches/tags by copying directories" are too abstract, and really not
relevant. Why should I care how SVN implements its branches
internally, as long as it works for the use cases I need?

The only concrete problem I've read so far (I don't remember if it was
in this thread or another one) is that copying the parent of all
branches (or tags) shows up as a revision when you "svn log" the
branch. So okay, that's one thing. Any others?

[1] http://subversion.apache.org/contributing.html

--
Johan

[Andreas Krey]

On Sat, 18 May 2013 19:33:10 +0000, Thorsten Sch�ning wrote:
...

> That's not an argument at all, because all one does in other SCMs is
> creating branches and tags. What you really should argue is what all
> devs think is common sense about branches and tags

You mean like 'I expect tags to be immutable out of the box, and have
the VCS not modify them with perfectly normal operations, at least not
without adding -f or something to them'?

> and why Subversion
> doesn't fulfill those requirements.

Just do 'svn cp ..../trunk ..../tag/thistag' twice accidentally,
and you see how it's bokren.

Subversion does not *support* tags (or branches), like C doesn't
support object-oriented programming. You can do the respective
things, but for instance, you can't ask subversion to tell you
the existing branches.

[Andreas Krey]

On Sat, 18 May 2013 19:33:10 +0000, Thorsten Sch�ning wrote:

> Guten Tag Z�,

> am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
>
> > The only difference between subversion and other SCM systems
> > is that other systems offer support for labeling and adding useful info
> > to those revisions, while Subversion doesn't.

You can always put them into the tag commit.

> Which useful info besides the name, and always present things like a
> revision, timestamps, who made the commit etc. is this?

Like 'which commit it is', in a useful way. Right now it is pretty
impossible to even find the tags that were made on commits of
a given branch's history. Like a 'svn log' that marks each
such commit with the names of the tags made there.

> And how does
> one benefit of those additional info compared to the lack of
> structuring of branches and tags those SCMs provide compared to
> Subversion?

All that structure is implicit. Unless someone tells you, you
have no ways to deduce which paths of a subversion repository
are meaningful to check out and which aren't.

[Andreas Krey]

On Sat, 18 May 2013 17:24:33 +0000, Z� wrote:
...

> Compared to how other SCM systems handle tags, subversion also doesn't
> have tags as a separate concept. Subversion provides a way to pinpoint
> each commit objectively and unambiguously by specifying specific
> revisions.

Not even that. You can easily modify the same file in multiple
branches in the same commit. :-)

...

> Let's put it this way: if that was actually a tag then it could also be
> argued that any file system supports branching/tagging.

Not quite, the file system does not store ancestry information on the
new partial tree. But svn's refusal to make tags write-protected by
default is the larger issue here.

[Andreas Krey]

On Sat, 18 May 2013 22:16:48 +0000, Johan Corveleyn wrote:
...

> Please be concrete, and give examples of what really bothers you as a
> user or an admin in your daily work. Saying that "branches are not
> first class", or "I don't like it that Subversion implements
> branches/tags by copying directories" are too abstract, and really not
> relevant. Why should I care how SVN implements its branches
> internally, as long as it works for the use cases I need?

It doesn't. Write protectings tags is obviously a pain in the ass;
<anecdotal>the admins of 'my' production repo still didn't manage to
disallow additions to tag directories</evidence>, and googling for the
problem doesn't even turn up any hints that are within the subversion
project pages. Let alone provide an easy way for users to override
that (like adding -f).

> The only concrete problem I've read so far (I don't remember if it was
> in this thread or another one) is that copying the parent of all
> branches (or tags) shows up as a revision when you "svn log" the
> branch. So okay, that's one thing. Any others?

The good old "'svn commit file; svn log' doesn't show the commit to
file" issue?

[Johan Corveleyn]

On Sat, May 18, 2013 at 11:15 PM, Andreas Krey <a.k...@gmx.de> wrote:
> On Sat, 18 May 2013 22:16:48 +0000, Johan Corveleyn wrote:
> ...
>> Please be concrete, and give examples of what really bothers you as a
>> user or an admin in your daily work. Saying that "branches are not
>> first class", or "I don't like it that Subversion implements
>> branches/tags by copying directories" are too abstract, and really not
>> relevant. Why should I care how SVN implements its branches
>> internally, as long as it works for the use cases I need?
>
> It doesn't. Write protectings tags is obviously a pain in the ass;
> <anecdotal>the admins of 'my' production repo still didn't manage to
> disallow additions to tag directories</evidence>, and googling for the
> problem doesn't even turn up any hints that are within the subversion
> project pages. Let alone provide an easy way for users to override
> that (like adding -f).

Okay, that's another concrete example (built-in support for
write-protecting tags), thanks.

Personally, I don't find this to be a big deal. I use a (perl)
pre-commit hook that was once posted to this list for protecting tags.
Also, if someone makes a mistake, and the pre-commit hook would
somehow not catch it, I'll see it in my post-commit mails, and can
easily correct the problem.

But I agree that built-in support for this would be much better. It's
one of those little things that can add up (if you have to set it up
all yourself with hooks), especially in large installations.

BTW: an easy way to implement an override would be to require a
specific word in the commit message. It's a bit low-tech, but it works
pretty well (and you have a nice trace of someone making a conscious
decision to override a control). For instance, we have a part of our
repository which is an ivy repository (with jars): there we don't want
jars to be modified, only added (with a new version number in the
filename). In the case a jar still needs to be updated, the magic word
"jarupdateallowed" allows it (and this is of course nicely mentioned
in the pre-commit error message in case you try it without the magic
word).

>> The only concrete problem I've read so far (I don't remember if it was
>> in this thread or another one) is that copying the parent of all
>> branches (or tags) shows up as a revision when you "svn log" the
>> branch. So okay, that's one thing. Any others?
>
> The good old "'svn commit file; svn log' doesn't show the commit to
> file" issue?

Sorry? What issue is that?

I'm talking about the fact that 'svn mv ^/branches ^/twigs' will show
up in 'svn log ^/twigs/branchX' for every branch (which looks like a
sort of cross-branch commit then).

I don't find this a big deal either. But like so many things, it will
probably bother someone.

--
Johan

[Daniel Shahaf]

Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200:
> On Sat, May 18, 2013 at 11:15 PM, Andreas Krey <a.k...@gmx.de> wrote:
> > The good old "'svn commit file; svn log' doesn't show the commit to
> > file" issue?
>
> Sorry? What issue is that?
>

This one is actually in the FAQ. It's inherent to how mixed-revision
working copies work, but the workaround is trivial:

svn commit file; svn log -l1 file

Daniel
(I didn't even have to specify an operative or peg revision, in this
particular case)

[Daniel Shahaf]

One way this could be implemented is by introducing more fine-grained
ACLs in authz files than the current ""/"r"/"rw" scheme.

(i.e., in the "To get a feature in the core, have a design thread on
dev@ and then someone implements the agreed-upon design" process, the
above is one potential design.)

[Zé]

On 05/18/2013 08:33 PM, David Chapman wrote:
> On 5/18/2013 12:01 PM, Z� wrote:
>> On 05/18/2013 07:16 PM, David Chapman wrote:
>>>
>>> You are pretty insistent that there is One True Way to use branches in
>>> development.
>>
>> No, I'm stating that if all a SCM does is track changes made to the
>> contents of a directory and you rely on changes made to that directory
>> to emulate branches, then there are some significant downsides to this
>> approach when compared with SCM systems which do offer support for
>> branching.
>
> You've missed the point. You have a specific definition of branching
> and do not believe that anything else can be called branching.

You are confused. This discussion is about how subversion lacks any
support for branching, which is quite obvious to anyone who understands
and acknowledges that all subversion does is track revision changes to a
file system. What you are insistingly referring to as branches is
nothing more than a copy of a particular subdirectory (i.e., the trunk)
into another subdirectory (i.e., branches), which is nothing more than a
plain recursive directory copy operation on a file system. The
operation doesn't change its name or nature (tag, trunk, simple
server-side directory copy) depending on the directories which are
copied around the repository. Is that so hard for you to understand?

> In your
> message to Thorsten Sch�ning, you said that branch history should be
> deleted if the branch is deleted. That is fundamentally in opposition
> to the definition of Subversion, which is meant to retain all of a
> project's history.

Again, that's wrong. The only thing that leads subversion to track how
a subdirectory is copied around in the repository is the fact that this
is not a branching operation: this is nothing more than a plain file
system operation.

The point of this whole discussion is that subversion does not support
branching, and therefore subversion users have to rely on the "let's
copy the trunk directory somewhere in the repo to simulate
tags/branches" hack to make do. Instead of relying on this hack,
subversion would be significantly improved if it actually supported
branches. How come you've replied so many times to this discussion if
you are so oblivious to what has been discussed so far?


<snip other misconceptions/>

--
Z�

[Dave Huang]

On May 19, 2013, at 3:20, Zé <jose....@gmx.com> wrote:

> You are confused. This discussion is about how subversion lacks any support for branching, which is quite obvious to anyone who understands and acknowledges that all subversion does is track revision changes to a file system.

I use branches in SVN all the time… you might take a look at the SVN Book for documentation if you're confused about how to do it: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html

HTH, HAND.
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: kh...@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 37 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

[Zé]

On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
> So what's the actual problem (or problems) with SVN's branching and
> tagging? Where does it hurt your workflow? What would make SVN not
> "hurt you" in that way?
>
> Please be concrete, and give examples of what really bothers you as a
> user or an admin in your daily work. Saying that "branches are not
> first class", or "I don't like it that Subversion implements
> branches/tags by copying directories" are too abstract, and really not
> relevant. Why should I care how SVN implements its branches
> internally, as long as it works for the use cases I need?

This has already been repeated multiple times. Didn't you followed the
thread?

Again, the problem is that subversion does not support branches or tags.
All it supports is basic file operations on a file system, and they
are not adequate for simulating branches or tags.

here's a small, concrete, reproducible example.

1) Create a brand new repository:

$ svnadmin create /tmp/repository


2) Set the repo initial layout:

$ svn mkdir branches tags trunk


3) Populate the trunk:

$ svn checkout file:///tmp/repository working_copy
$ cd working_copy/trunk
$ touch main.c
$ svn add main.c
$ svn commit -m "Initial import"


4) Start a feature branch by copying the trunk directory to a dedicated
subdirectory:

$ svn copy file:///tmp/repository/trunk
file:///tmp/repository/branches/awesome_feature


5) Work on the feature:

$ svn checkout file:///tmp/repository/branches/awesome_feature/ feature
$ cd feature
$ touch good_idea_but_undoable.c
$ svn add good_idea_but_undoable.c
$ svn commit -m "This is a dead-end development branch, doomed to be a
complete waste of developer's time"


6) Delete a development branch subdirectory:

$ svn delete file:///tmp/repository/branches/awesome_feature


7) This is the problem:

$ svn checkout --revision 3 file:///tmp/repository/branches wc
$ cd wc && tree

ze@ubuntu:wc$ tree
.
└── awesome_feature
├── good_idea_but_undoable.c
└── main.c

1 directory, 2 files


--
Zé

[Zé]

On 05/19/2013 09:33 AM, Dave Huang wrote:
> I use branches in SVN all the time� you might take

Read the thread.

--
Z�

[Branko Čibej]

I said before and I'll say again: you're making assumptions about what
branches are based on some model that doesn't fit reality. If Subversion
does not support your workflow, then replace Subversion, or change your
workflow. Stop insisting that your definition of a branch is a universal
truth.

[Zé]

On 05/19/2013 09:51 AM, Zé wrote:
>
> Again, the problem is that subversion does not support branches or tags.
> All it supports is basic file operations on a file system, and they
> are not adequate for simulating branches or tags.

Regarding tags, there's a better way to handle them in subversion:

1) Here's the repo status:

$ pwd
/tmp/working_copy/trunk

ze@ubuntu:trunk$ svn log --limit 3
------------------------------------------------------------------------
r6 | ze | 2013-05-19 09:58:38 +0100 (Sun, 19 May 2013) | 1 line

Marked v2
------------------------------------------------------------------------
r5 | ze | 2013-05-19 09:56:55 +0100 (Sun, 19 May 2013) | 1 line

Marked v1
------------------------------------------------------------------------
r1 | ze | 2013-05-19 09:35:25 +0100 (Sun, 19 May 2013) | 1 line

Initial import
------------------------------------------------------------------------

2a) This might be an alias to a "svn tag checkout v1"

$ svn checkout -r5 file:///tmp/repository/trunk wc
D wc/this_repo_state_would_be_v2.txt
A wc/this_repo_state_would_be_v1.txt
Checked out revision 5.

2b) This might be an alias to a "svn tag checkout v2"

$ svn checkout -r6 file:///tmp/repository/trunk wc
A wc/this_repo_state_would_be_v2.txt
A wc/main.c
Checked out revision 6.


These would be proper tags: they are immutable, they take over
essentially zero space in the repository, don't store redundant
information, and are completely free to be created and deleted. No
network traffic is needed.

I suspect that the only thing that would be needed for subversion to
offer proper support for tags is to implement a list that tracked label
names, revision number and the path to a specific subdir tracked by the
subversion repository.


--
Zé

[Zé]

On 05/19/2013 10:01 AM, Branko Čibej wrote:
> If Subversion
> does not support your workflow, then replace Subversion, or change your
> workflow.

Did you even browsed the thread? This whole thread is on how subversion
does not support branching, and how subversion would be even better than
what it is if it actually supported it.

And regarding suggestions on how to implement the workflow, feature
branches are one of two workflows which are explicitly covered by
subversion's documentation. Haven't you ever read the docs?

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

--
Zé

[Branko Čibej]

Your suspicions have led you astray. A tag should also be a
version-controlled object like any other. What you describe are aliases
for path@revision, which is not the same thing. Furthermore, to fit
Subversion's model, tags must be identifiable by URLs (just like every
other versioned object in a Subversion repository).

There are better ways to implement immutable tags in Subversion (we've
been considering at least three different approaches), and what you
propose isn't one of them.

[Thorsten Schöning]

Guten Tag Zé,
am Sonntag, 19. Mai 2013 um 10:20 schrieben Sie:

> You are confused. This discussion is about how subversion lacks any
> support for branching, which is quite obvious to anyone who understands
> and acknowledges that all subversion does is track revision changes to a

> file system.[...] Is that so hard for you to understand?

It seems as hard to understand as it seems to be hard to understand
for you that you didn't ever gave any common specification what
exactly a branch or tag is. You said something about metadata, but
gave no example what this meta data is, besides a name, or why someone
should benefit of only top level branches and tags.

[Branko Čibej]

On 19.05.2013 11:16, Zé wrote:
> On 05/19/2013 10:01 AM, Branko Čibej wrote:
>> If Subversion
>> does not support your workflow, then replace Subversion, or change your
>> workflow.
>
> Did you even browsed the thread? This whole thread is on how
> subversion does not support branching, and how subversion would be
> even better than what it is if it actually supported it.

No. This whole thread is about you insisting that Subversion's model
does not contain a first-class objec that would fit your definition of a
branch. Your definition is only one of a myriad possibilities.

We know about the quirks and shortcomings -- and also strenghts -- of
Subversion's object model. Your going on about them does not change them
in any way. Your proposals always assume that it's OK to change the
model. It is not, for reasons that I've already stated elsewhere.

[Thorsten Schöning]

Guten Tag Zé,
am Sonntag, 19. Mai 2013 um 10:51 schrieben Sie:

> 7) This is the problem:

[...]

This was surely not the problem, the thread started because of
changed revision numbers, you seem to be the only who wants to remove
history of changes.

[Thorsten Schöning]

Guten Tag Andreas Krey,
am Samstag, 18. Mai 2013 um 22:41 schrieben Sie:

> You mean like 'I expect tags to be immutable out of the box, and have
> the VCS not modify them with perfectly normal operations, at least not
> without adding -f or something to them'?

This sounds like Subversion technically supports tags, just with the
caveat that you have to deal with "-f" yourself. From my use case I
like that tags are writable by default because that's what I need.

[Thorsten Schöning]

Guten Tag Andreas Krey,
am Samstag, 18. Mai 2013 um 22:55 schrieben Sie:

> All that structure is implicit. Unless someone tells you, you
> have no ways to deduce which paths of a subversion repository
> are meaningful to check out and which aren't.

But that's nearly the same with any other SCMs which support branches
and tags as "1st class sobjects". You have always to options to decide
what is a branch or tag, something special in the data model or simply
some kind of convention. The data model is a better way for knowing
automatically if something is a branch or tag, no doubt, but one
should consider the main purpose of SCMs during software development
and devs use conventions everywhere in their work. It's a known
concept with some valuable benefits, e.g. flexibility.

Besides that, knowing what a branch or tag is is only one aspect, this
tells you nothing about it's purpose and therefore to know if it is
meaningful to anybody, useful to checkout or something else. Purposes
of branches and tags need always to be communicated between humans.

[Branko Čibej]

On 19.05.2013 11:46, Thorsten Schöning wrote:
> Guten Tag Andreas Krey,
> am Samstag, 18. Mai 2013 um 22:55 schrieben Sie:
>
>> All that structure is implicit. Unless someone tells you, you
>> have no ways to deduce which paths of a subversion repository
>> are meaningful to check out and which aren't.
> But that's nearly the same with any other SCMs which support branches
> and tags as "1st class sobjects". You have always to options to decide
> what is a branch or tag, something special in the data model or simply
> some kind of convention. The data model is a better way for knowing
> automatically if something is a branch or tag, no doubt, but one
> should consider the main purpose of SCMs during software development
> and devs use conventions everywhere in their work. It's a known
> concept with some valuable benefits, e.g. flexibility.
>
> Besides that, knowing what a branch or tag is is only one aspect, this
> tells you nothing about it's purpose and therefore to know if it is
> meaningful to anybody, useful to checkout or something else. Purposes
> of branches and tags need always to be communicated between humans.

I do agree, however, that being able to list the tag and branch names
associated with a particular versioned object would be nice. The trouble
is that it's not exactly obvious what that really means in the context
of Subversion's object model. In other words, hand-waving is not a good
feature specification. :)

[Johan Corveleyn]

On Sun, May 19, 2013 at 10:51 AM, Zé <jose....@gmx.com> wrote:
> On 05/18/2013 09:16 PM, Johan Corveleyn wrote:
>>
>> So what's the actual problem (or problems) with SVN's branching and
>> tagging? Where does it hurt your workflow? What would make SVN not
>> "hurt you" in that way?
>>
>> Please be concrete, and give examples of what really bothers you as a
>> user or an admin in your daily work. Saying that "branches are not
>> first class", or "I don't like it that Subversion implements
>> branches/tags by copying directories" are too abstract, and really not
>> relevant. Why should I care how SVN implements its branches
>> internally, as long as it works for the use cases I need?
>
>
> This has already been repeated multiple times. Didn't you followed the
> thread?

Of course I read it, but it's very hard to find the real points buried
in the thread, in between all the abstract unsubstantiated talk.

Thanks for spelling out the single thing that bothers you in SVN's
branching implementation. Again: I don't care about the religious
point about SVN implementing its branches with (cheap) copies ...
whatever.

So you want that branches/tags are completely gone without a trace
when you're done with them? Why? To save disk space or something? To
hide secrets?

I consider this so not a problem. On the contrary, this is an
important feature of subversion: never ever lose anything that has
ever been committed (okay, there's the long-standing request for an
obliterate feature in case you really want something gone ... but
that's completely orthogonal to branches and tags).

What's the problem with awesome_feature remaining available from history?

One day, someone remembers this awesome feature that didn't work out
at the time: "Hey, do you remember how we implemented that? I'd like
to take a look at that (historic) attempt and see if we can apply it
to mega_awesome_feature."

--
Johan

[Nico Kadel-Garcia]

On Sat, May 18, 2013 at 3:01 PM, Zé <jose....@gmx.com> wrote:
> On 05/18/2013 07:16 PM, David Chapman wrote:
>>
>>
>> You are pretty insistent that there is One True Way to use branches in
>> development.
>
>
> No, I'm stating that if all a SCM does is track changes made to the contents
> of a directory and you rely on changes made to that directory to emulate
> branches, then there are some significant downsides to this approach when
> compared with SCM systems which do offer support for branching.

You've been doing a lot more. I've read what you've written. You
consistently ignore your own previous claims, guidance or refutations
or information from others. You clearly want what you want, the way
you want it, and will accept nothing less than absolute confirmation
of your frankly unfounded claims about what branching and tagging
actually are and how they work, despite numerous references and
explanations.

I hate to do this on a really useful technical mailing list. But
you're clearly wasting everyone's time, and it's time to killfile you.

*plonk*.

[Andreas Krey]

On Sun, 19 May 2013 09:20:31 +0000, Z� wrote:
...

> file system. What you are insistingly referring to as branches is
> nothing more than a copy of a particular subdirectory (i.e., the trunk)
> into another subdirectory (i.e., branches), which is nothing more than a
> plain recursive directory copy operation on a file system.

Now may be the time for what the germans call 'Merkbefreiung'. It has
been pointed out to you that a 'svn cp' is *not* 'nothing more' than
a tree copy; it records the source of the operation to support future
merge operations.

[Volker Kopetzky]

+1 on *plonk*.

I admit, I had fun reading and this is a perfect end to the thread.

Thank-yous to Stefan, Branko and the other contributors in the thread.
There was definitely learning involved on my side (I did not learn most from Ze's replies)

"Let's just stop and think, before I lose face
Surely I can't fall, into a game of chase"
- Crave you

Peace,
Volker

[Les Mikesell]

On Sat, May 18, 2013 at 1:42 PM, Zé <jose....@gmx.com> wrote:
>
>> Besides
>> that, from my understanding filesystems do provide something which
>> could be argued as support for branches and tags because branches are
>> simply just work on something based on something other, which is
>> implemented as copying files and directories, and tags are something
>> which isn't as worked on as on branches, but is based on something
>> other, too, and may easily be implemented using copying things around
>> again and simply don't touch it anymore or e.g. using snapshots, which
>> would better guarantee an unchanged content.
>
>
> That's essentially what subversion does, as the only thing it actually does
> is track revisions made in a specific directory.

What do you mean by 'specific directory' here? It tracks the history
of anything that has a previous version or a source for a copy/move.
That is, you can move or copy any file or directory anywhere else and
be able to track back through its history. And that is somewhat at
odds with tracking merge history which may not happen on the same
boundaries.

> It works very well for a
> wide range of applications, in some cases better than other SCM systems, but
> the lack of support for branches does represent a a shortcoming.

I suppose theoretically you could use some namespace tricks to branch
the entire repository to get the all-or-nothing effect you seem to
want without mapping it into subdirectories, but we have many separate
projects in one repository. 99% of what full-repo branching would
have to track would never be useful. It only makes sense to us to
branch at the project level - which meshes with the file system
mapping.

--
Les Mikesell
lesmi...@gmail.com

[Bob Archer]

> On 05/18/2013 08:33 PM, David Chapman wrote:

> > On 5/18/2013 12:01 PM, Zé wrote:
> >> On 05/18/2013 07:16 PM, David Chapman wrote:
> >>>
> >>> You are pretty insistent that there is One True Way to use branches
> >>> in development.
> >>
> >> No, I'm stating that if all a SCM does is track changes made to the
> >> contents of a directory and you rely on changes made to that
> >> directory to emulate branches, then there are some significant
> >> downsides to this approach when compared with SCM systems which do
> >> offer support for branching.
> >
> > You've missed the point. You have a specific definition of branching
> > and do not believe that anything else can be called branching.
>
> You are confused. This discussion is about how subversion lacks any support for
> branching, which is quite obvious to anyone who understands and
> acknowledges that all subversion does is track revision changes to a file system.
> What you are insistingly referring to as branches is nothing more than a copy of
> a particular subdirectory (i.e., the trunk) into another subdirectory (i.e.,
> branches), which is nothing more than a plain recursive directory copy
> operation on a file system. The operation doesn't change its name or nature
> (tag, trunk, simple server-side directory copy) depending on the directories
> which are copied around the repository. Is that so hard for you to understand?

I disagree here. A branch is more than "a plain recursive directory copy operation on a file system." It has ancestry since it is pointed to its parent. This allows for merges from the parent to the branch. Svn log will show the revision history of a file from the branch back up to the parent path. Also blame goes back to the parent history as well. If a branch were "only a copy" then blame would only show, right after the branch, the person that made the branch.

You keep saying "svn doesn't support branches" yet I use branches every day. While there is no way to "list branches" it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own.





>
>
> > In your
> > message to Thorsten Schöning, you said that branch history should be

> > deleted if the branch is deleted. That is fundamentally in opposition
> > to the definition of Subversion, which is meant to retain all of a
> > project's history.
>
> Again, that's wrong. The only thing that leads subversion to track how a
> subdirectory is copied around in the repository is the fact that this is not a
> branching operation: this is nothing more than a plain file system operation.
>
> The point of this whole discussion is that subversion does not support branching,
> and therefore subversion users have to rely on the "let's copy the trunk
> directory somewhere in the repo to simulate tags/branches" hack to make do.
> Instead of relying on this hack, subversion would be significantly improved if it
> actually supported branches. How come you've replied so many times to this
> discussion if you are so oblivious to what has been discussed so far?
>
>
> <snip other misconceptions/>
>
> --

> Zé

[Bob Archer]

> Guten Tag Zé,
> am Sonntag, 19. Mai 2013 um 10:20 schrieben Sie:
>
> > You are confused. This discussion is about how subversion lacks any
> > support for branching, which is quite obvious to anyone who
> > understands and acknowledges that all subversion does is track
> > revision changes to a file system.[...] Is that so hard for you to understand?
>
> It seems as hard to understand as it seems to be hard to understand for you
> that you didn't ever gave any common specification what exactly a branch or
> tag is. You said something about metadata, but gave no example what this
> meta data is, besides a name, or why someone should benefit of only top level
> branches and tags.

Ze,

Wait... did you say a few message ago that you don't think a branch is a branch, because when you delete the branch the history of the path is still in the repo? That's what your example seemed to show. I think people want obiliterate to deal with that issue. You can delete any path and still see it in the history if you ask for it.. Isn't keeping that history the whole point?

BOb

[Les Mikesell]

On Tue, May 21, 2013 at 9:23 AM, Bob Archer <Bob.A...@amsi.com> wrote:
>>>
>> You are confused. This discussion is about how subversion lacks any support for
>> branching, which is quite obvious to anyone who understands and
>> acknowledges that all subversion does is track revision changes to a file system.
>> What you are insistingly referring to as branches is nothing more than a copy of
>> a particular subdirectory (i.e., the trunk) into another subdirectory (i.e.,
>> branches), which is nothing more than a plain recursive directory copy
>> operation on a file system. The operation doesn't change its name or nature
>> (tag, trunk, simple server-side directory copy) depending on the directories
>> which are copied around the repository. Is that so hard for you to understand?
>
>

> You keep saying "svn doesn't support branches" yet I use branches every day. While there is no way to "list branches" it would be possible. I think the current implementation records the parent path in the branch, but not vice versa...

Of course you can 'list branches' as long as you follow and remember
_your_ convention for where they are. You can also delete them to the
extent that they don't show up in this list (even though they can
still be accessed with peg revision syntax and the actions show in the
log history of the parent directory). This is nicer in many ways
than just having one special-case 'branch' namespace, especially when
you have many projects in the same repository and/or you like to
separate your release, QA, and experimental branches so different
groups don't have to deal with the clutter from the others.
Subversion doesn't force you to follow good conventions (and I think
this thread started because someone didn't and the rename of a
directory above where they put a branch was recorded as a change in
both the branch and its parent), but you can if you want.

> I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own.

Subversion always tracks 'copy from', but not 'copy-to'. In one way
it is correct to say that subversion doesn't have a special concept
for branches, but it is equally correct to say that every copy is
handled like a branch.

--
Les Mikesell
lesmi...@gmail.com

[Andrew Reedick]

> -----Original Message-----
> From: Bob Archer [mailto:Bob.A...@amsi.com]
> Sent: Tuesday, May 21, 2013 10:24 AM
> To: Zé; us...@subversion.apache.org
> Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>
> .. snip

>
> You keep saying "svn doesn't support branches" yet I use branches every
> day. While there is no way to "list branches" it would be possible. I
> think the current implementation records the parent path in the branch,
> but not vice versa... I assume svn doesn't do this because it would be
> a change to the parent path and the svn design avoids modifying the
> repository on its own.

There are two definitions of branches; svn's definition of a branch (i.e. a dir) and the high-level definition of a branch (theory.) The reason why svn doesn't "support branches" is because a svn branch is just a dir, a dir that is only a branch because it is given special meaning by Humans. Internally, svn doesn't know or care if a dir is a branch or not.

The distinction is important because one of the theoretical benefits of branching is isolation. An outside change shouldn't affect the branch's contents. Unfortunately, changing the parent path of a branch injects a spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early. This is detailed in my original email that started this thread.

So when people say that svn doesn't have branches, they are saying that
a) svn has directory objects, not branch objects, i.e. a svn branch is a branch by human convention only,
b) svn dirs lack the special protections expected of branches (e.g. being isolated from outside change),
c) svn dirs lack the special abilities expected of branches, such as computing ancestry reliably.

Fortunately, in practice, "dirs-as-branches" works fine for the most part and any limitations tend to be minor.

> While there is no way to "list branches" it would be possible.

No-ish. In the average case, "list branches" is easy. Just iteratively run 'log --stop-on-copy'. However, there are edge cases that prevent "list branches" from being deterministic or otherwise make determining ancestry complicated.

For example, is this a rename (to fix a misspelling) or a case where someone combined two steps: 1) creating a new branch and 2) deleting an obsolete branch?
svn copy branches/ofo-1.0 branches/foo-1.0
svn rm branches/ofo-1.0
svn ci
... creates revision 100 ...

If I want to find the start of the branch, I run 'svn log --stop-on-copy ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me if rev 100 is the start of the branch or whether it's just a spelling fix (in which case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who created rev 100 provided a meaningful commit message.

[Bob Archer]

> On Tue, May 21, 2013 at 9:23 AM, Bob Archer <Bob.A...@amsi.com> wrote:
> >>>
> >> You are confused. This discussion is about how subversion lacks any
> >> support for branching, which is quite obvious to anyone who
> >> understands and acknowledges that all subversion does is track revision
> changes to a file system.
> >> What you are insistingly referring to as branches is nothing more
> >> than a copy of a particular subdirectory (i.e., the trunk) into
> >> another subdirectory (i.e., branches), which is nothing more than a
> >> plain recursive directory copy operation on a file system. The
> >> operation doesn't change its name or nature (tag, trunk, simple
> >> server-side directory copy) depending on the directories which are copied
> around the repository. Is that so hard for you to understand?
> >
> >
> > You keep saying "svn doesn't support branches" yet I use branches every day.
> While there is no way to "list branches" it would be possible. I think the current
> implementation records the parent path in the branch, but not vice versa...
>
> Of course you can 'list branches' as long as you follow and remember _your_
> convention for where they are. You can also delete them to the extent that they
> don't show up in this list (even though they can still be accessed with peg
> revision syntax and the actions show in the

True, I can look at the branches folder. However, we keep branches for all revisions in the same branches folder.

What I meant is I can't be in a working copy with a repo path of ^/trunk and have it tell me what branches (copies) have been made from that path. Once again, a nice to have, but not a must have... since yes, our naming conventions are sufficient to identify the info we need.

> log history of the parent directory). This is nicer in many ways
> than just having one special-case 'branch' namespace, especially when you
> have many projects in the same repository and/or you like to separate your
> release, QA, and experimental branches so different groups don't have to deal
> with the clutter from the others.
> Subversion doesn't force you to follow good conventions (and I think this thread
> started because someone didn't and the rename of a directory above where
> they put a branch was recorded as a change in both the branch and its parent),
> but you can if you want.
>
> > I assume svn doesn't do this because it would be a change to the parent path
> and the svn design avoids modifying the repository on its own.
>
> Subversion always tracks 'copy from', but not 'copy-to'. In one way
> it is correct to say that subversion doesn't have a special concept for branches,
> but it is equally correct to say that every copy is handled like a branch.

Right, so this "copy-from" info is exactly what makes the "copy" a "branch" or more than just a file system copy. that's the point I was trying to make.

>
> --
> Les Mikesell
> lesmi...@gmail.com

[Bob Archer]

> > .. snip
> >
> > You keep saying "svn doesn't support branches" yet I use branches
> > every day. While there is no way to "list branches" it would be
> > possible. I think the current implementation records the parent path
> > in the branch, but not vice versa... I assume svn doesn't do this
> > because it would be a change to the parent path and the svn design
> > avoids modifying the repository on its own.
>
> There are two definitions of branches; svn's definition of a branch (i.e. a dir)
> and the high-level definition of a branch (theory.) The reason why svn doesn't
> "support branches" is because a svn branch is just a dir, a dir that is only a
> branch because it is given special meaning by Humans. Internally, svn doesn't
> know or care if a dir is a branch or not.
>
> The distinction is important because one of the theoretical benefits of
> branching is isolation. An outside change shouldn't affect the branch's
> contents. Unfortunately, changing the parent path of a branch injects a
> spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early.
> This is detailed in my original email that started this thread.

True but doesn't the log of ^/projectname1/trunk also change when you commit something to ^/projectname2/trunk ?? Projects aren't isolated within the same repo either.

[Bob Archer]

> Guten Tag Andreas Krey,
> am Samstag, 18. Mai 2013 um 22:41 schrieben Sie:
>
> > You mean like 'I expect tags to be immutable out of the box, and have
> > the VCS not modify them with perfectly normal operations, at least not
> > without adding -f or something to them'?
>
> This sounds like Subversion technically supports tags, just with the caveat that
> you have to deal with "-f" yourself. From my use case I like that tags are
> writable by default because that's what I need.

Although, truly if there was a "tag" command that added metadata to a revision which I think someone showed an example of earlier in this thread, you could still use the "copy" command to get a writeable tag directory like you have now. Frankly, if you are writing to tags it is more like a branch. ;)

BOb

[Andrew Reedick]

> -----Original Message-----
> From: Johan Corveleyn [mailto:jco...@gmail.com]
> Sent: Saturday, May 18, 2013 4:17 PM
> To: Zé
> Cc: us...@subversion.apache.org; David Chapman
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

> So what's the actual problem (or problems) with SVN's branching and
> tagging? Where does it hurt your workflow? What would make SVN not
> "hurt you" in that way?
>
> Please be concrete, and give examples of what really bothers you as a
> user or an admin in your daily work. Saying that "branches are not
> first class", or "I don't like it that Subversion implements
> branches/tags by copying directories" are too abstract, and really not
> relevant. Why should I care how SVN implements its branches internally,
> as long as it works for the use cases I need?
>

> The only concrete problem I've read so far (I don't remember if it was
> in this thread or another one) is that copying the parent of all
> branches (or tags) shows up as a revision when you "svn log" the
> branch. So okay, that's one thing. Any others?
>

Correct, changing the parent dir of a branch injects a "spurious" log entry in your branches (or tags) sub dirs, which is morally wrong because branches (and tags) should be isolated from outside changes. I documented this in the original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you "svn copy ^/porject1 ^/project" to fix the naming problem then everything under branches and tags gets the spurious revision. The spurious revision also triggers on --stop-on-copy which needlessly complicates ancestry tracking.

However, given how svn works, I'm not sure that it is technically a technical issue. =) Instead, is it a "branches as first class objects" requirement?

>
> However, this discussion lacks focus, it sounds more like a
> philosophical debate, with large ideas being thrown against each other.
> If you want to get anything useful out of this discussion (be it
> planting the seeds for improvements to Subversion, or be it a deeper
> understanding for yourself of how to work effectively with svn), you'll
> have to get much more concrete.

IMO, it's not a philosophical debate per se, it's a requirements (or expectations) problem. We have two points of view. The first is the low-level technical point of view that is focused on being able to perform any operation at any point in the repository tree. The second is the high-level point of view that needs a VCS to manage baselines, track ancestry, track merges between baselines, etc. IMO, subversion right now is more of a VCS engine than a VCS "system." Basically, it's the trees versus the forest view.

The friction is that the high-level point of view folks are probably your primary customers. For example, when Subversion initially announced that merge tracking wasn't part of the initial architecture, I laughed and blew off svn as a complete waste of time due to intentionally lacking such a basic and essential VCS feature.

Now that svn has implemented merge tracking, tree merging, and the long overdue death of --reintegrate in 1.8, I think it's getting close to the point that svn needs to step back and consider the forest view, e.g. true branches, proper ancestry tracking (instead of --stop-on-copy), etc., in order to maintain relevance. Meaning, svn's paradigm/workflow will need to focus on baselines (aka branches) instead of files and dirs because, in my experience, VCS users are most concerned about slinging baselines around and tracking changes to baselines (i.e. has all work for the release (baseline) been completed, merged, and tested?)

Disclaimer: All IMHO.

[Thorsten Schöning]

Guten Tag Bob Archer,
am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie:

> Frankly, if you are
> writing to tags it is more like a branch. ;)

Of course, that's why it's all about definitions or conventions and my
writable tags are customer installations of our software which get
updated to new versions and are used to track configuration changes.
Nothing I would like to implement using only top level branches and as
no active development takes place on those directories, I see them
rather as tags, than branches.

[Andrew Reedick]

> -----Original Message-----
> From: Thorsten Schöning [mailto:tscho...@am-soft.de]
> Sent: Tuesday, May 21, 2013 12:30 PM
> To: us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

> Guten Tag Bob Archer,
> am Dienstag, 21. Mai 2013 um 17:54 schrieben Sie:
>
> > Frankly, if you are
> > writing to tags it is more like a branch. ;)
>
> Of course, that's why it's all about definitions or conventions and my
> writable tags are customer installations of our software which get
> updated to new versions and are used to track configuration changes.
> Nothing I would like to implement using only top level branches and as
> no active development takes place on those directories, I see them
> rather as tags, than branches.
>

I think of tag-branches as effort saving devices that spare me from having to
svn copy tags/PRODUCTION branches/production
vi branches/production/config.conf
...
svn rm tags/PRODUCTION
svn copy branches/production tags/PRODUCTION
when a hostname changes in prod and I need to backfill a config file.

Should we call them tag-branches or branch-tags? And should they be first class objects? ;-)

[Les Mikesell]

We sometimes like to tag a source revision, then add the resulting
binaries after the fact. Conceptually that's not a real change but
more of just the way things work. And we are moving towards letting
Jenkins build from the trunk or a branch, then using a plugin to tag
after a successful build. But,.I still miss the way CVS let you
easily 'float' known tag names to revisions (even mixed, cherry-picked
workspaces) to target subsequent operations like your nightly build or
the rollback version as you advance a deployment. Simulating that by
deleting and making a new tag seems awkward.

Since tag names are what you use by convention, if you wanted
immutable tags you could just as easily use
/path/tags/tag_name@revision as the name which will always contain the
same thing. It's not really any harder to pass around than any other
arbitrary name.

--
Les Mikesell
lesmi...@gmail.com

[Bob Archer]

> > So what's the actual problem (or problems) with SVN's branching and
> > tagging? Where does it hurt your workflow? What would make SVN not
> > "hurt you" in that way?
> >
> > Please be concrete, and give examples of what really bothers you as a
> > user or an admin in your daily work. Saying that "branches are not
> > first class", or "I don't like it that Subversion implements
> > branches/tags by copying directories" are too abstract, and really not
> > relevant. Why should I care how SVN implements its branches
> > internally, as long as it works for the use cases I need?
> >
> > The only concrete problem I've read so far (I don't remember if it was
> > in this thread or another one) is that copying the parent of all
> > branches (or tags) shows up as a revision when you "svn log" the
> > branch. So okay, that's one thing. Any others?
> >
>
> Correct, changing the parent dir of a branch injects a "spurious" log entry in
> your branches (or tags) sub dirs, which is morally wrong because branches (and
> tags) should be isolated from outside changes. I documented this in the
> original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you
> "svn copy ^/porject1 ^/project" to fix the naming problem then everything
> under branches and tags gets the spurious revision. The spurious revision also
> triggers on --stop-on-copy which needlessly complicates ancestry tracking.
>
> However, given how svn works, I'm not sure that it is technically a technical
> issue. =) Instead, is it a "branches as first class objects" requirement?

What do you mean by "spurious" log entries? When I look at the log (at least in the tsvn log viewer) I only see revisions that have changes on that path. I don't see every revision number unless I go to the project root path or repository root path.

<<snip>>

[Andrew Reedick]

> -----Original Message-----
> From: Bob Archer [mailto:Bob.A...@amsi.com]

> Sent: Tuesday, May 21, 2013 1:24 PM
> To: Andrew Reedick; Johan Corveleyn
> Cc: us...@subversion.apache.org; David Chapman
> Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

>

> What do you mean by "spurious" log entries? When I look at the log (at
> least in the tsvn log viewer) I only see revisions that have changes on
> that path. I don't see every revision number unless I go to the project
> root path or repository root path.
>

1. Create /tags/tag1, /tags/tag2, etc..
2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked down, and haven't be touched in months.
3. svn log -v --stop-on-copy ^/tags/tag1
svn log -v --stop-on-copy ^/tags/tag2
etc.
4. # Move your tags dir under a project1 dir
svn mv -m "" --parents ^/tags ^/project1/tags
5. svn log -v --stop-on-copy ^/project1/tags/tag1
svn log -v --stop-on-copy ^/project1/tags/tag2
etc.

Ooops. All of your immutable, static, locked down, haven't been touched in months tags now have a new revision, and they all share that revision in common. The parent dir change from "/tags" to "/project1/tags" is visible under the tag1, tag2, etc. baselines because svn doesn't know that "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. baselines.

However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't change, so the effect is mostly visual.

[Andrew Reedick]

> -----Original Message-----
> From: Les Mikesell [mailto:lesmi...@gmail.com]
> Sent: Tuesday, May 21, 2013 11:41 AM
> To: Bob Archer
> Cc: Zé; us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>

> Of course you can 'list branches' as long as you follow and remember
> _your_ convention for where they are. You can also delete them to the
> extent that they don't show up in this list (even though they can still
> be accessed with peg revision syntax and the actions show in the
> log history of the parent directory). This is nicer in many ways
> than just having one special-case 'branch' namespace, especially when
> you have many projects in the same repository and/or you like to
> separate your release, QA, and experimental branches so different
> groups don't have to deal with the clutter from the others.
> Subversion doesn't force you to follow good conventions (and I think
> this thread started because someone didn't and the rename of a
> directory above where they put a branch was recorded as a change in
> both the branch and its parent), but you can if you want.
>

Right, right, it's the user's fault for failing to predict future "namespace" needs. That the repository was created when the project was small and that the user in question inherited the repo aren't valid excuses either.

Next time I'll implement top level directory changes via 'svnadmin dump/load' to avoid spurious log entries under branches/tags.


Translation: Les, that wasn't a very realistic or helpful piece of advice.

[Les Mikesell]

On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>
>> What do you mean by "spurious" log entries? When I look at the log (at
>> least in the tsvn log viewer) I only see revisions that have changes on
>> that path. I don't see every revision number unless I go to the project
>> root path or repository root path.
>>
>
> 1. Create /tags/tag1, /tags/tag2, etc..
> 2. Pretend that your tag1, tag2, etc. dirs are immutable, static, locked down, and haven't be touched in months.
> 3. svn log -v --stop-on-copy ^/tags/tag1
> svn log -v --stop-on-copy ^/tags/tag2
> etc.
> 4. # Move your tags dir under a project1 dir
> svn mv -m "" --parents ^/tags ^/project1/tags

What operation would this correspond to in a VCS that had 'first
class' tags? Should svn disallow it to emulate them?

> Ooops. All of your immutable, static, locked down, haven't been touched in months tags now have a new revision, and they all share that revision in common. The parent dir change from "/tags" to "/project1/tags" is visible under the tag1, tag2, etc. baselines because svn doesn't know that "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. baselines.
>
> However, the Last Changed Revision of the tag1, tag2, etc. dirs doesn't change, so the effect is mostly visual.

Isn't it really just an artifact of using --stop-on-copy to mean
something it doesn't quite mean - or more practically an artifact of
having done a copy that might have been avoided with better planning
or conventions? Is there some documentation that recommends moving
the parent location of the tags after creating them? And again, in a
practical sense, would you prefer for subversion to have disallowed
that move? Or can you at least acknowledge that it didn't force you
to do it?

--
Les Mikesell
lesmi...@gmail.com

[Branko Čibej]

On 21.05.2013 19:50, Andrew Reedick wrote:
> Ooops. All of your immutable, static, locked down, haven't been touched in months tags now have a new revision, and they all share that revision in common. The parent dir change from "/tags" to "/project1/tags" is visible under the tag1, tag2, etc. baselines because svn doesn't know that "^/project1/tags" isn't/shouldn't be part of your "tag1", "tag2", etc. baselines.

In fact, it should, because you renamed the tags. The misconception is
that the names of the tags is "tag1" and "tag2"; that is not the case.
The names are /tags/tag1 and /tags/tag2 before the rename, and whatever
the paths are after the rename.

You cannot identify a directory (or branch or tag) just by its basename,
only the whole path is a unique identifier (within the repository).

[Branko Čibej]

Just to be clear -- I agree that the the result of 'svn log
--stop-on-copy' changes is confusing. And, as I said (much) earlier in
this thread, that's an unfortunate side effect of how renames are
currently implemented. Personally I've always viewed the --stop-on-copy
as a hack, and we really should invent a better way of identifying
branch points.

[Les Mikesell]

On Tue, May 21, 2013 at 1:13 PM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>
> Right, right, it's the user's fault for failing to predict future "namespace" needs. That the repository was created when the project was small and that the user in question inherited the repo aren't valid excuses either.

Your bigger problem will come when you add enough projects that the
size of the repository becomes impractical to manage. Then it will be
your fault for not predicting the growth...

> Next time I'll implement top level directory changes via 'svnadmin dump/load' to avoid spurious log entries under branches/tags.

And you'll find that is less than perfect too if you want to extract
and move things that did not have stable parent paths.

> Translation: Les, that wasn't a very realistic or helpful piece of advice.

I'd call realizing that most software isn't perfect being realistic,
and learning to live with the imperfections to be more helpful than
waiting for everything to work the way you expect. Maybe in this
specific case some kind of event metadata could be added to note your
intent to create a branch or tag and that could be used instead of
--stop-on-copy to avoid confusing what you think of as tags and other
copies.

--
Les Mikesell
lesmi...@gmail.com

[Andrew Reedick]

> -----Original Message-----
> From: Les Mikesell [mailto:lesmi...@gmail.com]
> Sent: Tuesday, May 21, 2013 2:33 PM
> To: Andrew Reedick
> Cc: us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>

> I'd call realizing that most software isn't perfect being realistic,
> and learning to live with the imperfections to be more helpful than
> waiting for everything to work the way you expect. Maybe in this
> specific case some kind of event metadata could be added to note your
> intent to create a branch or tag and that could be used instead of --
> stop-on-copy to avoid confusing what you think of as tags and other
> copies.
>

Metadata could work. A "svn mkbranch" command that would run "svn copy" plus "svn propset" indicating that this is a branch root. "svn copy" would be restricted from operating in the branches or tags dir (as indicated by another property.) "svn log --stop-on-branch" would then check for the metadata.

Although if I was going to modify the client that much, I might as well internally store branches as "^/UUID" and map the UUIDs to a human label, e.g. "project1/1.0" or "project1/trunk". That would eliminate the troublesome "admin" level dirs from the repo and essentially implement "true branches"? And this would only be a presentation change thus negating the need to change how svn works internally.

[Andrew Reedick]

> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Tuesday, May 21, 2013 2:32 PM
> To: us...@subversion.apache.org

> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

> On 21.05.2013 20:26, Branko Čibej wrote:
> >
> > You cannot identify a directory (or branch or tag) just by its
> > basename, only the whole path is a unique identifier (within the
> repository).

Yes, I understand why it happens and why it needs to happen.

> Just to be clear -- I agree that the the result of 'svn log --stop-on-
> copy' changes is confusing. And, as I said (much) earlier in this
> thread, that's an unfortunate side effect of how renames are currently
> implemented. Personally I've always viewed the --stop-on-copy as a
> hack, and we really should invent a better way of identifying branch
> points.
>

I don't think true renames will necessarily fix the problem. Conceptually, the problem is that the parent dir components of a branch/tag are superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", the "svn://server/repo/path/to" and "branches" path components are useless/meaningless to the average user. However, these superfluous dir components are visible to the client, which means they're accessible by, and thus modifiable by the client. Which makes them superfluous *and* dangerous. The client should only see and work with "--project project1 --branch 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a branch.

It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression.


Anyway, I'm nearly done with implementing my "find common ancestor" script that seems resistant to edge conditions, so I'll stop rambling.

[Branko Čibej]

On 21.05.2013 21:27, Andrew Reedick wrote:
> Anyway, I'm nearly done with implementing my "find common ancestor"
> script that seems resistant to edge conditions, so I'll stop rambling.

Ah ... if that's what started the whole thread ... have you considered
that the Subversion libraries already have that functionality, and that
it's accessible through a number of script language wrappers?

[Andrew Reedick]

> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: Tuesday, May 21, 2013 3:36 PM
> To: us...@subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>

> On 21.05.2013 21:27, Andrew Reedick wrote:
> > Anyway, I'm nearly done with implementing my "find common ancestor"
> > script that seems resistant to edge conditions, so I'll stop
> rambling.
>
> Ah ... if that's what started the whole thread ... have you considered
> that the Subversion libraries already have that functionality, and that
> it's accessible through a number of script language wrappers?
>

Will the libraries get tripped up by "spurious" revisions created by parent dir path changes?

[Les Mikesell]

On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick
<Andrew....@cbeyond.net> wrote:
>
> I don't think true renames will necessarily fix the problem. Conceptually, the problem is that the parent dir components of a branch/tag are superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", the "svn://server/repo/path/to" and "branches" path components are useless/meaningless to the average user.

Well, no. If I copy something from /proj1/branches/dev/branch001 to
/proj1/branches/qa/branch001 or on to /proj1/branches/prod/branch001
it isn't meaningless even though at the time of the initial copy and
possibly forever the contents are identical. 'Meaning' is imposed by
the user, not the tool.

> However, these superfluous dir components are visible to the client, which means they're accessible by, and thus modifiable by the client. Which makes them superfluous *and* dangerous.

No, it makes them useful.

> The client should only see and work with "--project project1 --branch 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a branch.

That's sort of like saying filesystems shouldn't have subdirectories
so users don't get confused... Some people might even believe that.

> It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression.

It's about organization. And letting you arrange your own conventions
to match your processes.

--
Les Mikesell
lesmi...@gmail.com