Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/13/2013 06:23 PM, Andreas Krey wrote: No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you*can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. Compared to how other SCM systems handle tags, subversion also doesn't have tags as a separate concept. Subversion provides a way to pinpoint each commit objectively and unambiguously by specifying specific revisions. The only difference between subversion and other SCM systems is that other systems offer support for labeling and adding useful info to those revisions, while Subversion doesn't. If you are referring to the ad-hoc method of copying the trunk/branch to a subdirectory then all that you're doing is copying the trunk directory to another directory in your repository. That may be a convenient hack, but that isn't exactly support for tagging. Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. -- Zé
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é jose.pas...@gmx.com wrote: What has been said regarding subversions lack of support for branching was, I think, quite clear. Well, no. The only thing you've made clear is that you don't like it or you don't understand how it is supposed to be used. Read what I've wrote. Stick to what I've actually said, and don't put words in other people's mouths. You have not explained why you lay your projects out so that you need to move the parent directories of your project around after creating branches. You either failed to understand what has been written or you're imagining claims. Please quote exactly where I made such a claim. Nor have you made any real suggestions about how it might be improved I've already did. I've suggested that it would be great if subversion supported branching. People already replied to this thread saying that that feature is currently on the back burner. Next time try not to be rude and do read the posts you're replying to. Zé
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 andrew.reed...@cbeyond.net 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: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
Guten Tag Zé, am Samstag, 18. Mai 2013 um 18:24 schrieben Sie: The only difference between subversion and other SCM systems is that other systems offer support for labeling and adding useful info to those revisions, while Subversion doesn't. Which useful info besides the name, and always present things like a revision, timestamps, who made the commit etc. is this? And how does one benefit of those additional info compared to the lack of structuring of branches and tags those SCMs provide compared to Subversion? If you are referring to the ad-hoc method of copying the trunk/branch to a subdirectory then all that you're doing is copying the trunk directory to another directory in your repository. That may be a convenient hack, but that isn't exactly support for tagging. That's not an argument at all, because all one does in other SCMs is creating branches and tags. What you really should argue is what all devs think is common sense about branches and tags and why Subversion doesn't fulfill those requirements. The only thing mentioned until now is that revision numbers can change in the way subversion handles branches and tags and that only because Subversion does provide features, like (re)structuring branches and tags in a hierarchical way, other SCMs simply doesn't provide. Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. You ignore the versioning part of Subversion and that it guarantees the state/history of branches and tags like any other SCM. Besides that, from my understanding filesystems do provide something which could be argued as support for branches and tags because branches are simply just work on something based on something other, which is implemented as copying files and directories, and tags are something which isn't as worked on as on branches, but is based on something other, too, and may easily be implemented using copying things around again and simply don't touch it anymore or e.g. using snapshots, which would better guarantee an unchanged content. Filesystems with snapshots for tags would again provide benefits over SMCs like git and their branching and tagging facilities because the user has more flexibility in organizing his contents. 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 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 andrew.reed...@cbeyond.net 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: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 18, 2013 at 07:33:10PM +0200, Thorsten Schöning wrote: ... Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. You ignore the versioning part of Subversion and that it guarantees the state/history of branches and tags like any other SCM. Besides that, from my understanding filesystems do provide something which could be argued as support for branches and tags because branches are simply just work on something based on something other, which is implemented as copying files and directories, Some filesystems support branching/tagging as a first order operation: e.g., with zfs you have 'zfs snapshot' for immutable tags and 'zfs clone' for (shared storage, copy on write) tags. http://man.freebsd.org/zfs and tags are something which isn't as worked on as on branches, but is based on something other, too, and may easily be implemented using copying things around again and simply don't touch it anymore or e.g. using snapshots, which would better guarantee an unchanged content.
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 dcchap...@acm.org wrote: On 5/18/2013 12:01 PM, Zé wrote: On 05/18/2013 07:16 PM, David Chapman wrote: You are pretty insistent that there is One True Way to use branches in development. No, I'm stating that if all a SCM does is track changes made to the contents of a directory and you rely on changes made to that directory to emulate branches, then there are some significant downsides to this approach when compared with SCM systems which do offer support for branching. You've missed the point. You have a specific definition of branching and do not believe that anything else can be called branching. In your message to Thorsten Schöning, you said that branch history should be deleted if the 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 torvalds@*.org 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 torvalds@*.org 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 torvalds@*.org 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; anecdotalthe admins of 'my' production repo still didn't manage to disallow additions to tag directories/evidence, and googling for the problem doesn't even turn up any hints that are within the subversion project pages. Let alone provide an easy way for users to override that (like adding -f). The only concrete problem I've read so far (I don't remember if it was in this thread or another one) is that copying the parent of all branches (or tags) shows up as a revision when you svn log the branch. So okay, that's one thing. Any others? The good old 'svn commit file; svn log' doesn't show the commit to file issue? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org 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 a.k...@gmx.de 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; anecdotalthe admins of 'my' production repo still didn't manage to disallow additions to tag directories/evidence, and googling for the problem doesn't even turn up any hints that are within the subversion project pages. Let alone provide an easy way for users to override that (like adding -f). Okay, that's another concrete example (built-in support for write-protecting tags), thanks. Personally, I don't find this to be a big deal. I use a (perl) pre-commit hook that was once posted to this list for protecting tags. Also, if someone makes a mistake, and the pre-commit hook would somehow not catch it, I'll see it in my post-commit mails, and can easily correct the problem. But I agree that built-in support for this would be much better. It's one of those little things that can add up (if you have to set it up all yourself with hooks), especially in large installations. BTW: an easy way to implement an override would be to require a specific word in the commit message. It's a bit low-tech, but it works pretty well (and you have a nice trace of someone making a conscious decision to override a control). For instance, we have a part of our repository which is an ivy repository (with jars): there we don't want jars to be modified, only added (with a new version number in the filename). In the case a jar still needs to be updated, the magic word jarupdateallowed allows it (and this is of course nicely mentioned in the pre-commit error message in case you try it without the magic word). The only concrete problem I've read so far (I don't remember if it was in this thread or another one) is that copying the parent of all branches (or tags) shows up as a revision when you svn log the branch. So okay, that's one thing. Any others? The good old 'svn commit file; svn log' doesn't show the commit to file issue? Sorry? What issue is that? I'm talking about the fact that 'svn mv ^/branches ^/twigs' will show up in 'svn log ^/twigs/branchX' for every branch (which looks like a sort of cross-branch commit then). I don't find this a big deal either. But like so many things, it will probably bother someone. -- Johan
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 a.k...@gmx.de wrote: The good old 'svn commit file; svn log' doesn't show the commit to file issue? Sorry? What issue is that? This one is actually in the FAQ. It's inherent to how mixed-revision working copies work, but the workaround is trivial: svn commit file; svn log -l1 file Daniel (I didn't even have to specify an operative or peg revision, in this particular case)
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 a.k...@gmx.de 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; anecdotalthe admins of 'my' production repo still didn't manage to disallow additions to tag directories/evidence, and googling for the problem doesn't even turn up any hints that are within the subversion project pages. Let alone provide an easy way for users to override that (like adding -f). Okay, that's another concrete example (built-in support for write-protecting tags), thanks. Personally, I don't find this to be a big deal. I use a (perl) pre-commit hook that was once posted to this list for protecting tags. Also, if someone makes a mistake, and the pre-commit hook would somehow not catch it, I'll see it in my post-commit mails, and can easily correct the problem. But I agree that built-in support for this would be much better. It's one of those little things that can add up (if you have to set it up all yourself with hooks), especially in large installations. 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.)
