savannah-hackers-public
[Top][All Lists]
Advanced

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

[Savannah-hackers-public] Re: Overwriting bare repositories' master


From: Sylvain Beucler
Subject: [Savannah-hackers-public] Re: Overwriting bare repositories' master
Date: Tue, 31 Oct 2006 00:38:38 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Oct 30, 2006 at 11:47:39PM +0100, Han-Wen Nienhuys wrote:
> Sylvain Beucler escreveu:
> >Hi,
> >
> >On Mon, Oct 30, 2006 at 06:55:34PM +0100, Han-Wen Nienhuys wrote:
> >>Sylvain Beucler escreveu:
> >>>Hello,
> >>>
> >>>I'm trying to setup a git hosting facility, such as repo.or.cz. The
> >>>facility provides a pre-initialized git repository only accessible
> >>>through git-shell.
> >>>repo_one$ git push 
> >>address@hidden:/srv/git/sources/administration.git \
> >>>  master:refs/heads/master
> >>
> >>Does this mean that we will get GIT support on savannah? Cool!
> >>
> >>We're experimenting with GIT for GNU LilyPond, so it would be really 
> >>nice to have distributed VC with minimum fuss.
> >
> >Cool. Do you want to create a repository for lilypond now? I can
> >create one; it is temporarily at http://cvs.sv.gnu.org/gitweb/ .
> 
> Does this already work with the savannah project memberships system?

Yes. git shared repos can be Unix-groups-based, which means this works
out of the box in Savane :)


> >Beware, that's a ZETA service ;)
> 
> There is no real hurry; we're making do with repo.or.cz and lilypond.org 
> currently.  But if there is a some sort fo regular system in place, I 
> think we wouldn't mind being one of the first to go to a DVC.

It is better if we get a few interested users to use the service, so
as to steer early in the right direction.


> Also, Jan and I are still having some quarrels on which distributed VC 
> we should standardize on (Jan being fan of bzr, and me of git -- we 
> haven't evaluated hg yet.)  Are you planning to support just git, or are 
> others on the horizon too?

Right now we implement what fits in my head ;) but this can change as
soon as there's people interested in maintaining and using another VCS
(and as long as SV can deal with the load). We begin to have a
flexible enough internal architecture so adding new VCSes becomes
easier, but don't get your hopes too high for the near future :)


> >>If you introduce GIT on savannah, it might be a nice idea to import all 
> >>of the 'live' CVS repositories automatically into a branch of a 
> >>per-project/per-module GIT repository. Importing a sizable CVS repo 
> >>actually takes quite a lot of time, so having the imports done already 
> >>makes it a lot easier to experiment for people.
> >
> >That sounds good. It will probably takes days, because there're lots
> >of repos, and SV is already a loaded machine, but automatic conversion
> >sounds very good.
> 
> It will take a long time, so maybe it's better to do this on request. I 
> recall that my machine (core duo 1.6ghz) chugged for several hours 
> converting the lilypond repository.
> 
> >It may be difficult to keep a GIT repository in sync with CVS until
> >people actually start using it. Did you already try a repository
> >conversion? Can this be done?
> 
> Keeping GIT updated with CVS is fairly easy. For lilypond, we have an 
> hourly cron that does a cvsimport. It does run a
> 
>   cvs rlog
> 
> getting info from the entire repository at savannah, but then it only 
> pulls in the new changes.

That sounds acceptable indeed (especially with commit hooks instead of
cron jobs).

Incidentally you may want to perform the cvsimport out of a local
rsync mirror (from rsync://cvs.sv.gnu.org::sources). I am not sure if
rsync is more efficient than rlog, but it might.


> The headaches start when you want to merge changes from GIT back into 
> CVS, but that can't be automated anyway.

You can tell me some more about it? This is something that would
probably be useful to document, if projects want to move progressively
to git (with a part of the team sticking to CVS and another part using
git in the first times, and with both repos kept in sync).

I remember a similar solution for GNU Arch in their wiki.

-- 
Sylvain




reply via email to

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