Re: Revision control

[olafBuddenhagen]

Hi,

On Wed, Jun 11, 2008 at 10:46:16AM +0200, Arne Babenhauserheide wrote:
> Am Dienstag 10 Juni 2008 22:11:20 schrieb olafBuddenhagen@gmx.net:

> > It doesn't seem to detain any of the Linux contributors, nor the
> > Xorg ones...
> 
> Not anymore, since they became used to it. 
> 
> One example: Up until 4 years ago, I was a Mac User who seldomly
> touched the console, but I don't grunt about having to use the console
> anymore, because I learned its ways. It's the same with not perfectly
> intuitive interfaces and similar. 

There is a great quotation (don't remember by whom): "The only intuitive
interface is the nipple. Everything else is aquired."

Something feeling intuitive depends solely on previous experience. It is
*always* subjective.

The git UI is somewhat less polished, and may be harder to get used to
for the average CVS-trained hacker population; but I don't think it
really has worse long-term usability in objective terms.

> - Make the commands most people use quickly accessible (like "hg up"
> instead of "git checkout -f" to update all files). 

"git-checkout -f" is definitely not a command one uses regularily. It's
roughly the equivalent of "cvs co -C".

I don't know what "hg up" does -- but if it indeed follows CVS, it is
something entirely different... "cvs up" roughly translates to
"git-pull". (Or "git-fetch && git-rebase origin" if you want to avoid
clobbering history when you have local changes.)

> > And in fact, the git developers never cease to point out that such
> > interfaces can be easily created for git. The fact that very little
> > actually exists in this way, only proves that in spite of any
> > initial grunting, people are quite fine using the less shiny but
> > fully powerful standard interface in the end.
> 
> No. It just proves that people can get used to any kind of workflow,
> however inefficient. 

Maybe it would prove that, if we make the assumption that git workflow
is inefficient... Which is something I totally fail to agree with.

> Forcing users to learn things which aren't strictly necessary for
> using a tool just steals their time. 

I don't agree here either. Understanding the fundamental concepts *is*
strictly necessary to use the tool properly. Without such understanding,
users can never be quite sure what the commands really do, and this
uncertainity is very frustrating, as well as time-consuming whenever in
a less familiar situation.

A tool that abstracts the internals too much may seem more friendly at
first, but in the long run it actually has worse usability IMHO.

> For pulling changes, Mercurial only touches the changed files inside
> the repository. If only a subset of the files changes, this access is
> superior (in terms of disk usage) to having all files in one pack or
> having to touch every changeset. 

Eh? Why would accessing a few objects in a single pack *ever* be less
efficient than accessing the same objects in per-file structures?

> - Git offers some things only few workflows need and offers you
> flexibility, 

Sanitizing history is important in any distributed project, regardless
of the workflow.

> but gets in your way with necessary garbage collection (for active
> projects), 

I doubt that really gets in your way... IMHO you are artifically
inflating this minor issue.

> and its syntax and use are confusing at times and almost always badly
> documented. 

Must be subjective as well -- I for my part didn't have any negative
experience with git documentation so far.

On Wed, Jun 11, 2008 at 10:02:33AM +0200, Arne Babenhauserheide wrote:
> Am Dienstag 10 Juni 2008 23:59:36 schrieb olafBuddenhagen@gmx.net:

> Still it's inconvenient for me to have to remember to repack the
> repository all the time to avoid having it eat all my diskspace. 

This is a circular discussion. Again, repacking is not something you
need to remember all the time, but rather something you will see the
need to do once the repository actually gets too large and/or too slow.

> And it is inconvenient, that when you just repacked the project I am
> following, but you didn't garbage collect for a month or so, I have to
> access the pack from the whole month in order to get the last few
> changes. 

Eh? Unless using a dumb transport, you *never* get anything but the
necessary changes.

And anyways, this is an internal detail -- I don't see how it is related
to covenience at all.

> If at some time the repository grows too big and you didn't ever gc
> before, I will have to access the whole project history to just get
> the few changes you did after I last pulled your code. 

?!?

I have a growing suspicion that you do not really understand how git's
object store works...

> And garbage collecting all the time destroys its advantage, as it will
> just create as many packs as you have revisions (as far as I
> understand it). 

Indeed... Though even that wouldn't be terribly inefficient in most
cases. But anyways, if you really need to, there is an option to repack
existing packs.

> > A revision control system is not a file system though. And running a
> > filesystem on it is not exactly the common use case... Certainly not
> > what we want to do with the Hurd repository.
> 
> Why not? 
> 
> Having a completely version controlled filesystem is something I'd
> love to have. 
>
> I don't only use Mercurial for code, but also for my websites and for
> every text I write. 
> 
> And I could well imagine a Hurd filesystem server which uses Mercurial
> as backend, so every single change in a file gets recorded and can be
> reversed at any time. 

I only can say that in spite of various attempts, AFAIK versioned
filesystems never got implemented in any mainstream system except VMS...
Personally, I'm not convinced it is a very good idea except perhaps for
very specific use cases.

Anyways, normal revision control systems are not really suitable for
such transparent use. Filesystems have no changesets, there are no
commit messages, etc. You *can* do it (there is a FUSE module for Linux
IIRC), but it is really a kludge.

And this is still totally unrelated to the question which version
control system to use for the Hurd repository...

> > And that is only one of the many many reasons why libraries are
> > usually inferior to the traditional UNIX approach of reusing code by
> > invoking other processes.
> 
> Now we're in a completely different field :) 
> 
> If you say "the basic design of Mercurial is inferior, regardless to
> its usability", I can't say if you're right or wrong. 

The point is that in git, like in UNIX shell, the interface is not
abstracted from the internals -- which means a somewhat steeper learning
curve, but offers a lot of advantages in the long run -- not excepting
usability.

-antrik-