[I'm sorry about turning this subthread into Subversion vs. Git rant] David Kastrup <dak@xxxxxxx> writes: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> David Kastrup <dak@xxxxxxx> writes: >>> Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: >>>> SVN branches are incredible confusing because they fail to >>>> distinguish the directory structure of the project's source tree >>>> from the arrangement of available latest versions. >>> >>> That is because there _is_ no difference. You just store different >>> versions in different places. What they are named is a convention, >>> nothing more, nothing less. >> >> Branching by copying (!) and tagging by copying (!!!) is abuse >> of the fact that copying in Subversion is cheap. > > Uh, no. A lot of work has been invested into ensuring that copying in > Subversion in cheap _exactly_ because of the design decision to > implement branching and tagging via copying. > > It is not an accident that copying is cheap. I guess that idea of implementing cheap tree copying and idea of implementing branches and tags as "full-copies" went hand in hand. My feeling is that it looks like designing around implementation, instead of implementing design. Implementing branches as copies, or in general as directory in filesystem hierarchy is not that bad idea... provided that one can flawlessly distinguish between branch and path in project, can detect where branch name ends and in-project path begins (perhaps with project/module name in the middle). Neverheless designing around idea of graph of revisions is, IMVHO, much superior design :-) >> Distinguishing between branch part of directory name by _convention_ >> is design mistake; the fact that the tool doesn't help to ensure that >> (a) tags lie on branch (b) tags _doesn't change_ is an example of this >> stupidity. > > How much have you worked with Subversion so far? I am doing quite a bit > of work with it, and the do-everything-via-copying paradigm does not get > in my hair. It actually means that I have to remember fewer commands. > And it is pretty easy to understand. If you know what you are doing, and have good established workflow... I was talking there about possibility of mistake (either accident, or invalid workflow) of either having tag which is not on a branch, or changing the tag (treating it as branch). Branches and tags _are_ different. And should be, IMHO, treated differently (well, up to a point) by SCM. >>> Really, Subversion is rather simple to understand. But it is not a >>> DVCS. Moving a history from one repository to another is not really >>> feasible unless you are doing straight mirroring. >> >> Subversion is simple if you are limited to simple things; but the >> same is true with Git. I find for example the whole 'properties' >> mechanism and its use seriously not simple. > > Granted, particularly concerning the external property. OTOH, it makes > the equivalent of git submodules rather cheap (and I actually still have > no idea how git submodules properly work and what implications they > have). Git submodules are roughly equivalent to svn:externals with peg revisions; I mean here that they refer not to some branch in some external repository, but to specific revision. This is the only sane design, as it assures that when checking out some historical revision, the state that is checked out will be the same for everybody. Please take into account however that submodules are quite new feature, and while underlying engine is solid, interface (UI) needs some polishing (and use cases). -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
