Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Sat, May 18, 2013 at 1:42 PM, Zé jose.pas...@gmx.com wrote: Besides that, from my understanding filesystems do provide something which could be argued as support for branches and tags because branches are simply just work on something based on something other, which is implemented as copying files and directories, and tags are something which isn't as worked on as on branches, but is based on something other, too, and may easily be implemented using copying things around again and simply don't touch it anymore or e.g. using snapshots, which would better guarantee an unchanged content. That's essentially what subversion does, as the only thing it actually does is track revisions made in a specific directory. What do you mean by 'specific directory' here? It tracks the history of anything that has a previous version or a source for a copy/move. That is, you can move or copy any file or directory anywhere else and be able to track back through its history. And that is somewhat at odds with tracking merge history which may not happen on the same boundaries. It works very well for a wide range of applications, in some cases better than other SCM systems, but the lack of support for branches does represent a a shortcoming. I suppose theoretically you could use some namespace tricks to branch the entire repository to get the all-or-nothing effect you seem to want without mapping it into subdirectories, but we have many separate projects in one repository. 99% of what full-repo branching would have to track would never be useful. It only makes sense to us to branch at the project level - which meshes with the file system mapping. -- Les Mikesell lesmikes...@gmail.com
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: 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: 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: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote: ... Maybe it is just my misconception, but I've always thought of the difference between svn and git as being that svn conceptually tracks complete revisions although sometimes it might generate or store differences for some operations or internal storage convenience, where git tracks changesets although it often has to generate complete revisions. That indeed is just a misconception. git even goes to define exactly how each commit (aka revision) is stored including its checksum. This even though is it then going to internally store that in a dense packfile format. The nature of branches seems to relate better to No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you *can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. SVN, instead of having branches as a separate concept, also stores whole trees, but instead additionally stores 'this came from there' or 'that was merged here' as a separate concept. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 12:23 PM, Andreas Krey a.k...@gmx.de wrote: On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote: ... Maybe it is just my misconception, but I've always thought of the difference between svn and git as being that svn conceptually tracks complete revisions although sometimes it might generate or store differences for some operations or internal storage convenience, where git tracks changesets although it often has to generate complete revisions. That indeed is just a misconception. git even goes to define exactly how each commit (aka revision) is stored including its checksum. This even though is it then going to internally store that in a dense packfile format. What it computes internally or uses as an internal storage isn't quite the point. Svn would also always compute the differences even though it really only cares about the full revisions.What does git do if you try to double-merge a change? Does it know about the previous merge by its changeset commit id, look at the contents that are already present, or just do it twice? The nature of branches seems to relate better to No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you *can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. I can see why it might be a problem to support concurrent nested branch changeset roots but that scenario is problematic any way you look at it. Why would it be a problem to support parallel branching roots - perhaps with some enforcement on the source/dest top levels having some common parent? SVN, instead of having branches as a separate concept, also stores whole trees, but instead additionally stores 'this came from there' or 'that was merged here' as a separate concept. But does 'that was merged here', really know about the commit changeset where the change originated? -- Les Mikesell lesmikes...@gmail.com
RE: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On Mon, May 13, 2013 at 12:23 PM, Andreas Krey a.k...@gmx.de wrote: On Mon, 13 May 2013 11:32:13 +, Les Mikesell wrote: ... Maybe it is just my misconception, but I've always thought of the difference between svn and git as being that svn conceptually tracks complete revisions although sometimes it might generate or store differences for some operations or internal storage convenience, where git tracks changesets although it often has to generate complete revisions. That indeed is just a misconception. git even goes to define exactly how each commit (aka revision) is stored including its checksum. This even though is it then going to internally store that in a dense packfile format. What it computes internally or uses as an internal storage isn't quite the point. Svn would also always compute the differences even though it really only cares about the full revisions.What does git do if you try to double-merge a change? Does it know about the previous merge by its changeset commit id, look at the contents that are already present, or just do it twice? Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge. That said, I don't even think you can specify in git what to merge it just merges all the changes. I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target. BOb The nature of branches seems to relate better to No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you *can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. I can see why it might be a problem to support concurrent nested branch changeset roots but that scenario is problematic any way you look at it. Why would it be a problem to support parallel branching roots - perhaps with some enforcement on the source/dest top levels having some common parent? SVN, instead of having branches as a separate concept, also stores whole trees, but instead additionally stores 'this came from there' or 'that was merged here' as a separate concept. But does 'that was merged here', really know about the commit changeset where the change originated? -- Les Mikesell lesmikes...@gmail.com
