Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 09.05.2013 22:08, Andrew Reedick wrote: > 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. 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 ato
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Thursday, May 09, 2013 4:35 PM > To: users@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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 10.05.2013 15:56, Stefan Sperling wrote: > 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? 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 -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 8:40 AM, 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.) > > 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Friday, May 10, 2013 9:57 AM > To: Andrew Reedick > Cc: Branko Čibej; users@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 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? 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.)
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. 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.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Friday, May 10, 2013 11:00 AM > To: Andrew Reedick > Cc: Branko Čibej; users@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 8:40 AM, 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.) > > > > 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? > 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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Fri, May 10, 2013 at 10:42 AM, Andrew Reedick 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
-Steve > -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Friday, May 10, 2013 08:41 > To: Andrew Reedick > Cc: Branko Čibej; users@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 > > 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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 11.05.2013 19:25, Zé wrote: > 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. I'll take the bait and ask you for the definition of the semantics of a "branch". -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 11, 2013 at 1:25 PM, Zé wrote: > 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. 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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 11, 2013 at 1:45 PM, 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. 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?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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."
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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 CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 9: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. 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> 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). 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).
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 03:21:15PM +, 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 10:37 AM, Stefan Sperling 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 lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, 13 May 2013 13:29:39 +, 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 -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, 13 May 2013 18:35:35 +, 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. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 14, 2013 at 4:33 PM, Zé 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!
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 14, 2013 at 3:33 PM, Zé 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Wednesday, May 15, 2013 11:05 AM > To: Zé > Cc: Subversion > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On Tue, May 14, 2013 at 3:33 PM, Zé 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. > 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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Wed, May 15, 2013 at 12:06 PM, 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. > 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Wed, 15 May 2013 13:06:52 +, 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. -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/15/2013 04:04 PM, Les Mikesell wrote: On Tue, May 14, 2013 at 3:33 PM, Zé 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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/15/2013 06:59 PM, Les Mikesell wrote: On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick wrote: 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. 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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 5/18/2013 9:37 AM, Zé wrote: On 05/15/2013 06:59 PM, Les Mikesell wrote: On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick wrote: 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. 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. 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 dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 18, 2013 at 9: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. 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. 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, 18 May 2013 19:33:10 +, 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 -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, 18 May 2013 19:33:10 +, 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 -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, 18 May 2013 17:24:33 +, 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 -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, 18 May 2013 22:16:48 +, 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; the admins of 'my' production repo still didn't manage to disallow additions to tag directories, 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? Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 18, 2013 at 11:15 PM, Andreas Krey wrote: > On Sat, 18 May 2013 22:16:48 +, 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; > the admins of 'my' production repo still didn't manage to > disallow additions to tag directories, 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200: > On Sat, May 18, 2013 at 11:15 PM, Andreas Krey 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)
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200: > On Sat, May 18, 2013 at 11:15 PM, Andreas Krey wrote: > > On Sat, 18 May 2013 22:16:48 +, 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; > > the admins of 'my' production repo still didn't manage to > > disallow additions to tag directories, 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. 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.)
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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? -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On May 19, 2013, at 3:20, Zé 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: k...@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++
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 19.05.2013 10:51, Zé 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? > > 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 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. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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 Dwc/this_repo_state_would_be_v2.txt Awc/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 Awc/this_repo_state_would_be_v2.txt Awc/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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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é
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 19.05.2013 11:08, Zé wrote: > 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 > Dwc/this_repo_state_would_be_v2.txt > Awc/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 > Awc/this_repo_state_would_be_v2.txt > Awc/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. 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. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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. :) -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sun, May 19, 2013 at 10:51 AM, Zé 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. > 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 > 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 18, 2013 at 3: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 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*.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sun, 19 May 2013 09:20:31 +, 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. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
+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 Am 19.05.2013 um 19:37 schrieb Nico Kadel-Garcia : > On Sat, May 18, 2013 at 3: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 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*.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> 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? > > > > > -- > Zé
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> 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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 9:23 AM, Bob Archer 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, May 21, 2013 10:24 AM > To: Zé; users@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.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> On Tue, May 21, 2013 at 9:23 AM, Bob Archer 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 > lesmikes...@gmail.com
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. 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. > > 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. > > >
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> 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
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Saturday, May 18, 2013 4:17 PM > To: Zé > Cc: users@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.
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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: Tuesday, May 21, 2013 12:30 PM > To: users@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? ;-)
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 10:54 AM, Bob Archer wrote: >> >> > 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. ;) > 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 lesmikes...@gmail.com
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? 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. <>
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, May 21, 2013 1:24 PM > To: Andrew Reedick; Johan Corveleyn > Cc: users@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.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Tuesday, May 21, 2013 11:41 AM > To: Bob Archer > Cc: Zé; users@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.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 12:50 PM, Andrew Reedick 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 lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
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). -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
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: > 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). 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. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 1:13 PM, Andrew Reedick 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Tuesday, May 21, 2013 2:33 PM > To: Andrew Reedick > Cc: users@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.
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Tuesday, May 21, 2013 2:32 PM > To: users@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.
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? -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Tuesday, May 21, 2013 3:36 PM > To: users@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?
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick 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 lesmikes...@gmail.com
RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Tuesday, May 21, 2013 3:53 PM > To: Andrew Reedick > Cc: Branko Čibej; users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > > 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. And there's a reason why 'pwd' returns '/home/userid' instead of '/dev/sda1/home/userid' or 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to your home dir. > > > 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. We'll have to agree to disagree. We're back at the low level "managing dirs" versus high-level "managing baselines" arguments/thinking/paradigms.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
> From: Andrew Reedick >> -Original Message- >> From: Les Mikesell [mailto:lesmikes...@gmail.com] >> Sent: Tuesday, May 21, 2013 3:53 PM >> To: Andrew Reedick >> Cc: Branko Čibej; users@subversion.apache.org >> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams >> aka Branches as First Class Objects? >> >> >> > 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. > > And there's a reason why 'pwd' returns '/home/userid' > instead of '/dev/sda1/home/userid' or > 'server-vol0.foo.net:/vol0/userid'. Or why 'cd ~' takes you to > your home dir. Well, "cd ~" is imposed by the shell environment, not by kernel. And /dev/sda1 being / is imposed by the kernel, not the shell; but the kernel only knew to map it that way because the user told it to. The issue is the same as with SVN. SVN does not know anything about what users mean by the URL paths; it only knows about the paths it implements. A higher level piece of software could do additional mappings and hide all those details - just like the kernel does for user level programs when it is told to map /dev/sda1 to /; but that higher level piece of software has to be configured to do that, just like the kernel does. >> > 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. > We'll have to agree to disagree. We're back at the low level > "managing dirs" versus high-level "managing baselines" > arguments/thinking/paradigms. As others have stated, SVN provides the engine to do the work - just like the kernel provides the engine to read the disk drive. However, unlike the kernel it has no higher level functions that do mappings it can understand. It's just the core, and while it is pretty smart about what it does it is also pretty dumb about what it doesn't do - just like a kernel file system driver is very smart about reading the file system but very stupid about what the directories or files the user puts in the file system mean. Or more to the point, you can think of it like this: Apache2 = Kernel - maps https://mysvnserver/svnrepopath to / SVN = File System Driver for the kernel Of course, "svnserve" mixes the two, but that's really the gist of it as it relates to your example. Ben
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 3:32 PM, Andrew Reedick wrote: > > We'll have to agree to disagree. We're back at the low level "managing dirs" > versus high-level "managing baselines" arguments/thinking/paradigms. > We're not completely opposed here. I can see the value of being able to note the 'top' of where you think a branch starts and constrain subsequent 'branch related' operations to that and things with the same parent revision history.But I can also see the value of being able to organize your branches under a parent tree to separate qa/release/feature/experimental/etc. sections, so I don't think completely hiding the path to branches is the right answer.And given subversion's ability to check out directories 'above' your project or branch level, I don't see how you can avoid a literal mapping into directories even if that doesn't match the more typical use. In any case, if you have ever published/announced a URL to your branch to the group that will use it, you have a bigger problem than with the tool itself if you change that location after the fact. Rather than trying to change history with a move you want to pretend didn't happen, maybe it would be better to just do a copy and have everyone aware that the location is new. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Andrew Reedick, am Dienstag, 21. Mai 2013 um 21:27 schrieben Sie: > It's about presentation. Keep the superfluous dir components > internal and hidden from the average user. Clearly a -1/dislike from me. :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@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
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: > In any case, if you have ever published/announced a URL to your branch > to the group that will use it, you have a bigger problem than with the > tool itself if you change that location after the fact. Rather than > trying to change history with a move you want to pretend didn't > happen, maybe it would be better to just do a copy and have everyone > aware that the location is new. ASF Infra have an httpd module that intercepts attempts to access a URL that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues a permanent redirect (301) response: https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf wrote: > Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: >> In any case, if you have ever published/announced a URL to your branch >> to the group that will use it, you have a bigger problem than with the >> tool itself if you change that location after the fact. Rather than >> trying to change history with a move you want to pretend didn't >> happen, maybe it would be better to just do a copy and have everyone >> aware that the location is new. > > ASF Infra have an httpd module that intercepts attempts to access a URL > that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues > a permanent redirect (301) response: > > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README Does that actually work with svn clients? Some time ago I tried to do a reverse-proxy in apache to a repository hosted on a different server and it worked when the target path was the same on the remote as what the client requested but when the path was different and mapped in the proxy, somehow the 'real' path leaked back to the client and kept it from working for some operations. Maybe in this case if they learn the real path it just works anyway. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Les Mikesell wrote on Tue, May 21, 2013 at 16:40:40 -0500: > On Tue, May 21, 2013 at 4:19 PM, Daniel Shahaf > wrote: > > Les Mikesell wrote on Tue, May 21, 2013 at 16:04:59 -0500: > >> In any case, if you have ever published/announced a URL to your branch > >> to the group that will use it, you have a bigger problem than with the > >> tool itself if you change that location after the fact. Rather than > >> trying to change history with a move you want to pretend didn't > >> happen, maybe it would be better to just do a copy and have everyone > >> aware that the location is new. > > > > ASF Infra have an httpd module that intercepts attempts to access a URL > > that has been moved (^/incubator/bar/foo to ^/baz/foo) and issues > > a permanent redirect (301) response: > > > > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svn_check_path/README > > Does that actually work with svn clients? Some time ago I tried to > do a reverse-proxy in apache to a repository hosted on a different That module just sends a 301 response, it doesn't try to transparently proxy anything. Daniel > server and it worked when the target path was the same on the remote > as what the client requested but when the path was different and > mapped in the proxy, somehow the 'real' path leaked back to the client > and kept it from working for some operations. Maybe in this case if > they learn the real path it just works anyway. > > -- >Les Mikesell > lesmikes...@gmail.com
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Tue, May 21, 2013 at 03:20:37PM -0400, Andrew Reedick wrote: > Metadata could work. A "svn mkbranch" command that would run "svn > copy" plus "svn propset" indicating that this is a branch root. More than a week ago, this exact idea was already mentioned: http://svn.haxx.se/users/archive-2013-05/0109.shtml In the *same* mailing list thread. Looks like this discussion has entered an infinite loop.
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/21/2013 06:10 PM, Stefan Sperling wrote: > Looks like this discussion has entered an infinite loop. ... which is a pity, because certain whole arcs of that loop are arguably off-topic for a users@ list. Design-related discussions really belong on dev@. -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
