On Thu, Jul 17, 2008 at 06:05:25PM +0200, David Kastrup wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > 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. Staying on trunk, try to compare your files foo and bar with version 1.0. With Git, it is simple git v1.0 -- foo bar but I don't think you can do that so easily with SVN. But the real problem with the do-everything-via-copying paradigm is that now revisions do not identify anything meaningful without some path. This leads to problems if you try to implement merge. In Git, it is simple -- merge is a commit with more than one parent. You cannot do like that in SVN. Instead, you have to track merges per file. This is not just waste of resources, but this merges is very difficult if not impossible to visulize in any useful way. But if you cannot see something, you cannot control it well. So, not accidently, in systems with inter-file branching, creating feature branches is discouraged. Besides having fewer commands doesn't necessary mean easier to learn or to use. If you have one command that conflates different concepts, it is usually more difficult than having a devote command per concept. Can you remove the concept of branches and merges and have your VCS still useful? Well, you can say "we don't use branches, every developer commits directly on trunk". The consequence of that choice is that a lot of work-in-progress code is pushed to trunk. But no one has the perfect foresight. Some ideas will turn out to be not so good. Some developers will not finish their work and will be reassigned to more urgent tasks. As result, just as release time approaches, you have a lot of unfinished crap in your trunk. Of course, if you don't care about quality of your software, it may be easier for you to work in this way. However, if you do care about quality, you have to use feature branches for WIP, and for this workflow to work, you need that merging is really easy. Git makes that for you, yet you may need to learn new concepts -- branching and merging. Thus comparision of what is easier or difficult is meaningless without defining goals. It is always easy to be sloppy and don't care... Dmitry -- 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
