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 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 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 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
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 05/18/2013 06:33 PM, Thorsten Schöning wrote: Guten Tag Zé, am Samstag, 18. Mai 2013 um 18:24 schrieben Sie: The only difference between subversion and other SCM systems is that other systems offer support for labeling and adding useful info to those revisions, while Subversion doesn't. Which useful info besides the name, and always present things like a revision, timestamps, who made the commit etc. is this? And how does one benefit of those additional info compared to the lack of structuring of branches and tags those SCMs provide compared to Subversion? Subversion doesn't offer tags explicitly. The closest it has is revision numbers, and the standard course of action is to simulate this feature by creating a dedicated subdirectory that is used exclusively to store copies of the trunk whose names are selected to reflect tags. Having said that, the "let's copy the trunk to a subdirectory" approach to simulate tags is not a problem, nor is it a shortcoming. People have emulated tags by storing tar files containing copies of the trunk, and that works well. If you are referring to the ad-hoc method of copying the trunk/branch to a subdirectory then all that you're doing is copying the trunk directory to another directory in your repository. That may be a convenient hack, but that isn't exactly support for tagging. That's not an argument at all, because all one does in other SCMs is creating branches and tags. What you really should argue is what all devs think is common sense about branches and tags and why Subversion doesn't fulfill those requirements. That has already been repeatedly stated. Again, using the ad-hoc directory copy/move operations to simulate branches stores all the changes in the repo's revision history for all eternity, even when creating short-lived development branches which don't go anywhere and end up being deleted. The only thing mentioned until now is that revision numbers can change in the way subversion handles branches and tags and that only because Subversion does provide features, like (re)structuring branches and tags in a hierarchical way, other SCMs simply doesn't provide. That's the least of anyone's concern. The issue is that behind those revision numbers there are real changes made to the repository, which are eternally kept there and are made available to anyone. If you create a directory, change some files and delete the directory, and each operation is individually committed to the repository, each of those operations are eternally made available in the repository. This means you can checkout a specific revision that presents you with any of those changes. If you resort to those operations to emulate development branches, which is the only way that subversion is able to emulate them, then you end up storing in your repository revisions that reflect dead-ends which didn't made their way into the trunk, and those revisions do have an influence in subsequent revisions committed to the repository. Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. You ignore the versioning part of Subversion and that it guarantees the state/history of branches and tags like any other SCM. You've missed the point. The point was that the suggested ad-hoc way to emulate tags with subversion is to copy a snapshot of the trunk to a subdirectory. That doesn't mean that a file system supports tags. Besides that, from my understanding filesystems do provide something which could be argued as support for branches and tags because branches are simply just work on something based on something other, which is implemented as copying files and directories, and tags are something which isn't as worked on as on branches, but is based on something other, too, and may easily be implemented using copying things around again and simply don't touch it anymore or e.g. using snapshots, which would better guarantee an unchanged content. That's essentially what subversion does, as the only thing it actually does is track revisions made in a specific directory. It works very well for a wide range of applications, in some cases better than other SCM systems, but the lack of support for branches does represent a a shortcoming. Zé
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 Sat, May 18, 2013 at 1:42 PM, Zé 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
