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

[Joris van der Hoeven]

On Thu, 30 Oct 2003, David Allouche wrote:
> > 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.

Not only renaming; I know that Arch does that. I mean that
editing a bunch of files or one file should basically be similar
from the TeXmacs point of view (this also means, for instance,
that one wants to do multi-file structured query-replacing,
or mix undo and version control).

> 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.

I know.

> The complexity of the issues involved are of the same magnitude as the
> complexity of a typesetting system.

Not sure about that though.

> 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.

The structure of a C++ is just a sequence of ASCII lines.

> 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.

Yes, this is getting closer to the kind of view I have of the situation.
Yet, I don't know yet exactly *how* integrated version control and
structured diff stuff should be with TeXmacs. But, once again,
our aim is to have someone full time working on that. If that works out,
then we will surely be able to come up with something adequate.
Also, after closer investigation, it may turn out that we might
use CVS or Arch or whatever as plug-ins.

> 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.

The main aim of using CVS is to attract developers by using a standard tool,
a bit like using C++ templates instead of my gencc module system.
Let us just do this for a year or so and see how things stand afterwards.

Of course, if other people on this list massively vote in favour of Arch,
then I might still change my mind. But even then, I am afraid that I will
not have the time now to change...

> 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):

Note also that this is not enough: another aim is to attract extern
developers, which is easier using a more standard tool...

>   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?"

Yes, but Arch has also many problems. Its advantages
over CVS do not outweight the loss in standardness.

>   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.

It will again take me a few days and I do not have this time.

>   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.

That is why I will mainly give write-access to the plug-in code.
This is better for the moment, because I am reorganizing so much stuff,
and I will get insane otherwise.

>   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.

...

But don't despair: the situation will be reconsidered next year.