4 ms·

When there's only one repo, there's no ambiguity about the content represented by a revision number. Revnums are perfectly adequate for the many situations in w

by arebop 17y ago

When there's only one repo, there's no ambiguity about the content represented by a revision number. Revnums are perfectly adequate for the many situations in which frequent coordination with a central repository is completely feasible. Git also does not require every file and subdirectory to be modified by every merge, so based on that criterion it's no more astonishing that SVN merge tracking can work than it is that Git merge tracking can work. SVN's merge tracking was an after-thought, and it was implemented using the general, user-visible, metadata facility (properties). So historically svn was prone to problems such as repeated merging, and today it's possible to make things complicated, and then manually edit and botch the complex merge history, and suffer. Fundamentally, svn:mergeinfo summarizes history rather than pointing only to merge-parents. I suppose the latter is what you mean when you speak of clear-thinking primitives. I wasn't involved in the mergeinfo design, but it seems less likely the result of muddled thinking than of a design decision recognizing that the entire revision graph isn't locally available to svn users and that the summary is sufficient under reasonable restrictions on usage. Your condemnation of svn as a "hopelessly hamstrung" "dead-end" seems derived more from your dismissal of centralized version control generally than from the particular details of svn's design or implementation. In that dismissal I think you're taking too narrow a view of the ways in which people work together.

dasil003 17y ago
Wow, what I said just sailed right over your head. Git also does not require every file and subdirectory to be modified by every merge... Uh, nooooooo... git always merges the whole repository. This makes merge tracking easy to implement in a complete way, and easy to reason about as a user. Fundamentally, svn:mergeinfo summarizes history rather than pointing only to merge-parents. I suppose the latter is what you mean when you speak of clear-thinking primitives. No, I'm referring to the fact that in git has a strict definition of both branches and the project tree, the notion of a merge isn't a primitive, it just sort of falls out of the primitive definitions naturally. Each revision in a git repo contains one and exactly one copy of the whole working tree. In Subversion the repository just has directories, some of which are project tree directories, and some of which are branches, and some of which are tags. That lack of clarity leads to all sorts of problems with basic functionality that VCSes should have. it seems less likely the result of muddled thinking than of a design decision recognizing that the entire revision graph isn't locally available to svn users and that the summary is sufficient under reasonable restrictions on usage. What it seems like is that the designers had only ever used CVS, so what they were working on seemed so advanced to them at the time, that they thought that "cheap copies" and partial checkouts were just icing on the cake and they had no idea of what they were trading away. However in hindsight it's clearly not worth munging everything together. You are far better forcing users to actually define branches and subprojects. The amount of work that svn saves you is insignificant next to the degradation of the information stored in the repository data structure. Your condemnation of svn as a "hopelessly hamstrung" "dead-end" seems derived more from your dismissal of centralized version control generally than from the particular details of svn's design or implementation. It might seem that way because you don't appear to have understood a word I said. Nothing I've said had anything to do with distributed development. Everything I've said is specifically about svn's primitive concepts, and dead-end is a perfect way to describe it. This ignorant defense of subversion needs to be stopped. I understand there are reasons people need to use subversion. I understand there are use cases that DVCSes don't fit. I certainly don't think git is the end-all-be-all of VCS. But to defend subversion without adequate understandings of its failings just makes you look bad. It's no different than a Java developer talking about how they don't see what's so great about Lisp macros. If you don't grok the concepts then any arguments you make are just noise.

by arebop 17y ago

dasil003 17y ago

Wow, what I said just sailed right over your head. Git also does not require every file and subdirectory to be modified by every merge... Uh, nooooooo... git always merges the whole repository. This makes merge tracking easy to implement in a complete way, and easy to reason about as a user. Fundamentally, svn:mergeinfo summarizes history rather than pointing only to merge-parents. I suppose the latter is what you mean when you speak of clear-thinking primitives. No, I'm referring to the fact that in git has a strict definition of both branches and the project tree, the notion of a merge isn't a primitive, it just sort of falls out of the primitive definitions naturally. Each revision in a git repo contains one and exactly one copy of the whole working tree. In Subversion the repository just has directories, some of which are project tree directories, and some of which are branches, and some of which are tags. That lack of clarity leads to all sorts of problems with basic functionality that VCSes should have. it seems less likely the result of muddled thinking than of a design decision recognizing that the entire revision graph isn't locally available to svn users and that the summary is sufficient under reasonable restrictions on usage. What it seems like is that the designers had only ever used CVS, so what they were working on seemed so advanced to them at the time, that they thought that "cheap copies" and partial checkouts were just icing on the cake and they had no idea of what they were trading away. However in hindsight it's clearly not worth munging everything together. You are far better forcing users to actually define branches and subprojects. The amount of work that svn saves you is insignificant next to the degradation of the information stored in the repository data structure. Your condemnation of svn as a "hopelessly hamstrung" "dead-end" seems derived more from your dismissal of centralized version control generally than from the particular details of svn's design or implementation. It might seem that way because you don't appear to have understood a word I said. Nothing I've said had anything to do with distributed development. Everything I've said is specifically about svn's primitive concepts, and dead-end is a perfect way to describe it. This ignorant defense of subversion needs to be stopped. I understand there are reasons people need to use subversion. I understand there are use cases that DVCSes don't fit. I certainly don't think git is the end-all-be-all of VCS. But to defend subversion without adequate understandings of its failings just makes you look bad. It's no different than a Java developer talking about how they don't see what's so great about Lisp macros. If you don't grok the concepts then any arguments you make are just noise.