Re: [Texmacs-dev] Arch mirror

[David Allouche]

On Tue, Sep 30, 2003 at 11:35:20AM -0700, address@hidden wrote:
> 
> At one time I asked why TeXmacs is not in the CVS at Savannah.
> After all, despite its limitations CVS is infinitely better
> than nothing at all. (Even if only Joris has commit access.)
> 
> At the time I asked this question, TeXmacs directory names
> were changed with each unstable release. This practice has
> stopped, so maybe the reasons which were given in response
> to my query then were not valid. (CVS has no sane method of
> dealing with renamed files.)
> 
> http://mail.gnu.org/archive/html/texmacs-dev/2003-04/msg00082.html
> http://mail.gnu.org/archive/html/texmacs-dev/2003-04/msg00085.html

The reason why I recommand Arch is because it has _none_ of the cited
problems, which were:

> 1) The system is bad from a technical point of view. For instance,
>    it is a nightmare to move files and directories around; precisely
>    the kind of thing which I do during a reorganization phase...

Arch has a variety of "tagging methods" (id-ing files and dirs, not in
the sense of CVS TAG) which make moving thing around painless.

Inexact patching of moved files is perfectly well supported: a
changeset can be applied on a tree where things have been renamed
without causing conflicts (as with regular patches).


> 2) The control I have over the order and the way changes are made in
>    the main branch are less fine-grained as is the case which
>    patches. This may also be due to the fact that I do not know well
>    how to use CVS. But the mere fact that I could not quickly learn
>    how to do so means that the tool is not that good.
> 
> 3) In another project where we do use CVS (as an experience
>    for me), I don't like it at all. I have the impression that
>    people very easily make changes without doing all necessary
>    checks themselves. As a consequence I spend *most* of the time
>    what is wrong and undoing changes made by others. In other words,
>    contributed patches usually are of a better quality than
>    contributions made via CVS.

Those problems do not arise in arch because of the way it is designed.
Changes only get in a tree when the tree owner takes an explicit
action. And there are a variety of ways of doing this for different
scenarios: "update", "replay", "star-merge", "sync-tree"...

Patch history is managed using a "patch log" system (each revision
creates a patch-log file in the metadata) which has very elegant
properties.

However I believe the problem is no longer technical: the cooperation
system is not going to change now because Joris decided he'll do a
better job than anyone else. And when it will change it will be
something obscure that only texmacs use.

If you are interested in using Arch or getting insights of what is
going on in the source just use my archive. You will find the name and
location of the archive on the Arch Wiki:

  http://gnuarch.org/bin/view/Main/ArchiveRegistry

The archive is still not up to date. I hope to fix it this week.

-- 
                                                            -- ddaa