www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Writable git repositories
Date Sun, 11 Oct 2009 08:12:28 GMT
comments inside.

what about the following idea which came to my mind while reading your post:

We have a mandatory SVN repo which is still the canonical one.

We additionally have a git repo hosted at apache which does dcommits to SVN via .git/hooks/post-receive.
So whenever someone does a git-push to this git repo, the commits will get committed to SVN
too. Additionally the export hook will add a line with the full sha1 of each git commit to
the checkin comment in SVN.

If the sync back to the git repo reads the checkin comment and detects the sha1, it will simply
skip importing this commit back to git.

If someone commits something to svn it will be updated to git as usual.

wdyt? just a quick thought, not sure how many traps there are we cannot solve but imho it's
worth trying. I think we should really try to get rid of this ugly problem that the sha1 changes
on the svn -> git sync.


--- On Sun, 10/11/09, Kevin Menard <nirvdrum@gmail.com> wrote:

> From: Kevin Menard <nirvdrum@gmail.com>
> Subject: Re: Writable git repositories
> To: infrastructure-dev@apache.org
> Date: Sunday, October 11, 2009, 4:30 AM
> Hi William,
> On Sat, Oct 10, 2009 at 5:30 PM, William A. Rowe, Jr.
> <wrowe@rowe-clan.net>
> wrote:
> > Here is the problem;
> >
> > The foundation has always been responsible for the
> contents of the foundation's
> > revision control systems, and assumes that
> responsibility upon a commit.  The
> > notices of each of these commits are broadcast to the
> relevant projects, who
> > are responsible for catching any irregularities and
> repairing them.
> I think all modern SCMs have some means of doing a post
> commit/checkin/push hook which can be used to send an email
> to the
> relevant commits list.

git definitely has

> > The is substantially different from individual
> development forks over which
> > nobody has an oversight role.  E.g. my git tree is
> not your git tree, and if
> > the git forks all exist at the foundation, the
> foundation suddenly grows a huge
> > liability without a sufficient oversight process.
> I'm not sure I follow you on this one.  My filesystem
> is also not your
> filesystem, so you don't see any of my code modifications
> until I
> commit them to the SVN server.  git doesn't change
> that.  

But git may change this!
Because in reality my git tree is your git tree and maybe we additionally share some feature
branch somewhere else. But where ever I push my repo to, the sha1 will stay the same!

I think it's the same story as we had with bugzilla vs Jira. Bugtracking and documentation
has almost the same relevance as SCMs do.

> I'd still
> strongly advocate for open development of software and I
> think
> projects will largely do the right thing there.  So, I
> would expect to
> see regular pushes of local developer repositories to
> remote branches.
>  If they don't, that's not a failing of the tool, that's a
> failing of
> the process.
> As for non-committers, I think it's non-issue.  They
> can have a local
> repository and host elsewhere -- that wouldn't be the ASF
> responsibility.  And all contributions to a project
> should be held to
> the same standard as the current JIRA-based patch
> submission.
> > So not to badmouth git, but infra is responsible for
> ensuring that the technical
> > aspects of the foundation (infra managed, or not)
> satisfy the legal/procedural
> > responsibilities for this foundation to remain a
> 501(c)3 and mitigate the risks
> > appropriately.
> If this really is the problem, I'm interested in hearing a
> bit more
> about how git is a problem.   From my
> (possibly naive) standpoint,
> there's no difference between git, SVN, or any other SCM
> for that
> matter on this point.
> Regards,
> Kevin


View raw message