Re: Considering teaching plumbing to users harmful

[Dmitry Potapov <dpotapov@gmail.com>]

On Thu, Jul 17, 2008 at 06:05:25PM +0200, David Kastrup wrote:
> Jakub Narebski <jnareb@gmail.com> 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