[Texmacs-dev] Versioning (was: My public plugin repository)

[David Allouche]

Since you are open to discussion, I would like to discuss this a bit
more. CVS does make sense _a priori_ but I am convinced a closer
examination of the issue shows that this is not the right choice.

Apologies for that lengthy post, but I have to try to tilt the balance
before it is too late.

On Wed, Oct 29, 2003 at 06:01:17PM +0100, Joris van der Hoeven wrote:
> 
> > I bet you that one or two years from now, when Arch will be better known
> > and you will have been sufficiently pissed off by CVS wrongness, you
> > will want to make the switch. But at this time there will be an existing
> > base of CVS users and you will be stuck with it.
> 
> That is possible. But it can also be that within a few years from now
> we will have developed something ourselves which is even more integrated
> with TeXmacs. In fact, we are trying to employ someone in collaboration
> with Saarbrucken to do exactly that. The point is that current solutions
> are too much file based and carry to little structure. Ideally speaking,
> a file system is just a structured document and this point of view will
> be further developed in a native way inside TeXmacs.

I do not understand what you mean. You seem complain about the inability
of versioning system to cope with filesystem operations (like renamings),
but that is something Arch does very well.

Another interpretation may be that the basic line-based diff/patch tools
are not good enough. Which is true. But a good version control system is
_much more_ than a wrapper around diff/patch. The complexity of the
issues involved are of the same magnitude as the complexity of a
typesetting system.

It must also be noted that structured diff do not apply well to source
code where changes which are not structurally significant (whitespace,
layout, etc.) are important.

A recurrent topic in discussions about Arch is the use of "pluggable
diff/patch". If you come up with a good structured diff/patch (which
supports inexact patching too) the way to get the best value is to just
plug this component in an existing version control system, not
reimplement the whole version control system.

The solution I propose is using Arch right now (it is still time to
change) and later extend it to support pluggable diff/patch when TMDIFF
will be ready for production. So TeXmacs documents and source code will
all be versioned in a optimal way. And this will be based on a very sane
design maintained by a very active and fast growing community. A better
tool for less work, this is a win-win decision.

> > One of the reasons I choose to work in free software is avoiding this
> > kind of nonsense. When there are good free tools (especially GNU
> > projects...) for a task, there is no reason to use crappy "industry
> > best-practices" tools.
> >
> > Please take a rational approach. What are your needs, what are the
> > available tools, and which one better fits the bill?
> 
> That is exactly what I do and I came to the conclusion that nothing
> fits my needs. Arch might come closest, but is far from optimal.
> CVS is about the worst solution, but at least it is well known and
> it will attract developers. I decided to conform to what other
> users and developers expect (cf. my opinion poll). But the solution
> is certainly temporary.

I am glad to see you admit that CVS is "about the worst solution
available". I hope you have enough sense to see that the "de-facto
standard" excuse is not enough of a reason.

You mention your "opinion poll" as the reason why Arch should not be
used. I had a close look at that thread, here is my analysis (not
counting myself and yourself):

    Arch      (2): Teemu, Norbert
    Something (2): Alvaro, Michael
    CVS       (2): Daniel, Philippe
    
    Teemu Ikonen
      Asked for up-to-date Arch repository
    
    Alvaro Tejero Cantero
      Asked for some cooperative tool
    
    Daniel Bump
      Recalled he asked about CVS and admitted it was problematic
    
    Then you asked "about CVS/Arch: if I use such a system", nothing CVS
    specific here.
    
    Michael Graffam
      Said he'd like something.
    
    Philippe Audebaud
      Argumented for CVS. The only part which may be understood as
      "exclusively CVS" is:
        Even if everybody knows well about its imperfections, it is widely
        used, people are familiar with it [...]
      Which just boils down to "it is a de-facto standard, let's use it".
    
      But he also noted that the development model of TeXmacs is closest
      to the development model of Linux. This model cannot in any sane
      sense be supported by CVS (and Linus never wanted to use it) but
      it can be well supported by Arch (though it is admittedly not as
      good as BitKeeper).
    
    Daniel Bump
      Said how CVS was better than exchanging diffs.  I bet he does not
      know about Arch.  Then you made a point about how CVS sucks and I
      explained how Arch has none of the problems.
    
    Then you said you will choose CVS even it if sucks because it is
    "standard".

    Norbert Nemec
      Said in a recent post he finds its improbable that you would come
      up with something as good as Arch for C++. Did not speak for CVS.

The two persons who asked for CVS had experience with it, admitted it
was problematic, and probably did not know about how Arch does not have
these problems. Philippe made a good argument which can clearly be
understood as a reason _not_ to use CVS. Daniel went at length on the
problems of CVS that Arch does not have.

The only person to talk for CVS because it is a de-facto standard was
Philippe.


I am confident I can convince in half an hour any CVS user, who actually
listen, that Arch is better when choosing a VCS from scratch.

Here are some Q&A:

  Q. Doesn't CVS suffice?
  A. That is not the right question, that should be "what is the extra
     cost of using a tool which does not have the problems of CVS?"
     The only reason to use CVS instead of Arch is that it provides a
     central control point. Not really a good reason for a free software
     project. And there are plenty of reasons to use Arch instead.

  Q. It takes time setting up with a CVS already in place.
  A. It takes no time to set up once you have a ssh access to a public
     webspace, which is needed for CVS anyway.

  Q. It takes to get used to and errors by people who do not know Arch
     may very well cause extra delays, as with any "new" solution.
  A. CVS too takes time to get used to.  And actually one person's
     mistake cannot break other people's tree with Arch because it takes
     an explicit action to merge changes from other developpers.

  Q. Oh, I though there already was a CVS in place that was being used.
  A. No. Things are being set up from scratch. No legacy.

  Q. If I had a small bugfix for a public project and it was using a
     Arch server then I would be hesitant in submitting it since it'd
     require me to read extra documentation, install some sort of
     client, etc.
  A. The same goes for CVS, that is what the Savannah patch manager is
     for.

  Q. But all (older?) projects use CVS!
  A. All older projects use Motif or Athena widgets, that was the only
     good solution at that time.

  Q. Are there public Arch hosting service?
  A. Sourceforge, Savannah and actually any ISP. You just need (s)ftp
     access and http/anonftp. There is no need for specific server-side
     software.

  Q. Does it integrate as well as CVS in existing editors?
  A. There are emacs modes for Arch, but there is no real need for this.
     A handful of shell aliases is good enough (whole tree commits, no
     need to commit files individually).

  Q. I like to be able to see the file history in Emacs to figure out
     which original patch merged in the main branch causes breakage in
     my specific configuration. Can Arch do this?
  A. Actually this problem does not map well because the whole workflow
     happens differently. If devo A makes a big patch, then it is merged
     in the maintainer M's tree, then you merge with M, the merge
     operation appears as one big patch in your tree, but it includes
     the changelogs for all patches which have been merged directly or
     indirectly.
     You can easily grep those changelogs to see which patches modified
     the file you are interested in, then either examine the problematic
     patch or get revisions where it was first made to do a full-context
     GUI diff. The only requirement is that archive in which the
     original change was made is available online.
     And since the patch is whole-tree, you get the complete context of
     the change.


This is it. There is no technical reason not to use Arch and there is no
"popular demand" to use CVS instead. And there are plenty of reasons to
use Arch and not CVS, it just happens that many people are not aware of
them.

-- 
                                                            -- ddaa