savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-help-public] coreutils is moving to distributed version co


From: Jim Meyering
Subject: Re: [Savannah-help-public] coreutils is moving to distributed version control
Date: Wed, 24 May 2006 13:30:51 +0200

Sylvain Beucler <address@hidden> wrote:
> On Tue, May 23, 2006 at 02:08:10PM +0200, Jim Meyering wrote:
>> Hello,

Hi Sylvain,

Thank you for the quick reply.

>> Currently, the coreutils package uses CVS for version control.  However,
>> I am shifting coreutils development to git -- or maybe even mercurial.
>> Will savannah support git or mercurial soon?
>
> I would welcome a bit more information about those. Do they only need
> a plain "download area" accessible with sftp or rsync+ssh? That may be
> setup quickly enough. Maybe on a non-standard port, but quickly
> enough.
>
> A concern I have with those tools, is that unlike with CVS, any
> project member can alter/damage the history, willingly or by mistake.
> Did you think of this issue and is it ok with you?

[FWIW, one can remove history with cvs (using admin -o), but I suppose
 you know that, and have disabled the `feature' on savannah.  ]

This wouldn't change the current state for coreutils development,
since in that case, the golden repository is on my desk, and what's
on savannah is just a mirror.  Of course, I do realize that this
set-up is not the norm.

With git or hg, it'd be similar.  I'd develop using my own, local
repository (including `pull'ing from other contributor trees), and
occasionally `push'ing to the savannah repository.  I presume I'd be
the only one with the right to push, just as is the case now (currently
I rsync to a host from which a savannah cron job pulls the cvs repo).

With git:
Pushing requires ssh access.
Anonymous read-only access is most efficient via the git-native protocol
I.e., people would run `git clone git://remote.machine/path/to/repo.git/'
Another way to provide read-only access is via http.
For details, see the Repository Administration section here:
  http://www.kernel.org/pub/software/scm/git/docs/everyday.html

> With Arch, archives are 'append-only' thanks to a dedicated sftp
> patch, but I doubt we'd be able to apply the same technique for any
> SCM. If it's just a matter of blocking the 'rm' command in sftp, that
> could be quickly done, but depending on git usage patterns, that may
> not be desirable.
>
>
>> I would also consider using monotone.
>
> Their network support is not satisfying enough yet, as I mentioned in
> gnu-prog-discuss. Unless there's something new about it?

I hesitate to say much about it, since I haven't used it enough,
but so far, it is not my first choice.

...
> Didn't you try GNU Arch btw?

No.
Here are some of the things that make git attractive to me:
  the sensible-to-me basic command set (though admittedly, there's a lot
    of plumbing -- I haven't spent much time with tools like cogito, yet)
  the number of good use-case descriptions and tutorials
  the amazing amount of features and infrastructure that it already provides
  the number of contributing developers
  the number of people and the scale of projects using it

> Also if you have some notes about your experiments I'd be personaly
> interested in them :)

I do have preliminary notes, but am swamped now.
If you ask again in a week or two, maybe I'll have something publishable.

>> But I do use mercurial, too, and find it quite usable, featureful
>> and well-maintained.
>
> Ok. When you say you use 'git', does that mean 'bare git' or 'cogito'?

I haven't used cogito.  If savannah provides git support,
then afaik, cogito will work fine, too.

> Does supporting git implies supporting mercurial, darcsgit and the
> like?

No.  They're totally independent.

> Last, what would be your acceptable level of "support" at Savannah? Is
> simple hosting enough in a first step, or would you also need commit
> notifications / web browsers / etc.?

Simple hosting would be a great start.

Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]