[Gc] Cmake and contribution model (Git)

Boehm, Hans hans.boehm at hp.com
Mon Aug 8 17:28:22 PDT 2011


I'm OK with just moving to git, if you're more comfortable with that.

I haven't had a chance to explore github much.  Is there a way to give access to the original cvs maintainers, at least to the extent they still want it?  Ivan is currently doing essentially all of the check-ins (many thanks!), but I'd be more comfortable if others also had access, at least as a backup.

My guess is that we don't want to maintain both cvs and git versions much past the point at which we're sure that everything works and we want to stay with git.  Otherwise that seems like unnecessary overhead.  Or are there platforms that have only cvs clients?

Presumably pull requests don't work through firewalls on the submitter's side.  Thus I suspect many of us will still end up trafficking in patches.  But that's no worse than what we have now.

Hans

> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Monday, August 01, 2011 4:56 AM
> To: gc at linux.hpl.hp.com; Nicola Brisotto; Boehm, Hans
> Cc: Kevin Bowling; Christopher Bertels; Alexander Gavrilov; Sylvain
> Ageneau
> Subject: Re[2]: [Gc] Cmake and contribution model (Git)
> 
> Hi Hans and Nicola,
> 
> I wrote:
> > Nicola Brisotto wrote:
> > > So my real question is: why don't you move to git?
> > > A lot of open-source project are using git, it enable an easier
> contribution model. Give a look at gitorious.org, people can branch and
> then send you a merge request and you don't need patch anymore.
> > > There are script that help to import a cvs repository. I'm not an
> expert of cvs but I could help you to move to git.
> > IMHO, git is a tool not an aim, so while there is a small group of
> people contributing to the project, it's not, probably, forth moving to
> git. (At the mean time, recently we have a problem with a CVS folder
> renaming which we wouldn't have if the project had already been
> git'ed.)
> 
> Hans wrote:
> > I'd probably favor sticking with cvs for now, since I think that's
> what most of us are familiar with. (Svn seems close enough for
> experience to mostly carry over.) If we did want to switch to a git-
> like model, I've also heard arguments for Mercurial recently, but don't
> have any experience with it.
> 
> 
> I finally created a git clone of our cvs. Git, as a distributed CRM
> system, looked to me to be a bit convenient to operate with branches
> and process 3rd-party patches. I've chosen github (vs gitorious) server
> as more popular. (It shouldn't be difficult to move the repo to some
> other eg. back to sourceforge in the future.)
> 
> I haven't compared Git with Hg.
> 
> Besides, cloning the repo with the full history, I've:
> 1. split it into 2 projects - libatomic_ops and bdwgc itself (the
> latter lacks libatomic_ops folder);
> 2. added gc6x-branch (comprised of official pre-v7 releases);
> 2. added major downstream forks - mono_libgc and gcc_boehmgc branches
> originated from gc6x-branch (to simplify comparison and merging into
> upstream). (Although, I don't know how I'll update these branches from
> their origins.)
> 
> "release" branch contains the latest official release (either alpha or
> final).
> 
> Tags: every official release has the corresponding tag, e.g.
> libatomic_ops-7_2alpha6, gc7_2alpha6.
> 
> URLs:
> libatomic_ops - https://github.com/ivmai/libatomic_ops/
> bdwgc - https://github.com/ivmai/bdwgc/
> 
> Currently, to make bdwgc work, libatomic_ops tree should be inside
> bdwgc tree. Eg.:
> cd ~
> git clone git://github.com/ivmai/libatomic_ops.git
> git clone git at github.com:ivmai/bdwgc.git
> ln -s  ~/libatomic_ops ~/bdwgc/libatomic_ops
> 
> About maintaining CVS: I think it's worth to keep CVS in sync with Git
> for a while.
> 
> Patch processing:
> 1. Old, traditional approach - send me a diff file (git diff master);
> 2. A new one - send me a pull(merge) request.
> 
> Regards,
> Ivan Maidanski



More information about the Gc mailing list