On 2008-05-08 00:58:48 -0700, Steven Grimm wrote:
> On May 8, 2008, at 12:43 AM, Karl Hasselström wrote:
>
> > Or even _only_ pull from the git repo. That repo would have to
> > have some kind of hook to make sure that it's always up-to-date,
> > then -- just a cron job won't do -- but I'm sure that can be done.
>
> If you control both the svn repo and the git repo, you can get close
> to that with an svn commit trigger, but even then there'll be a race
> condition when you want to dcommit. You either have to be able to
> pull from the svn repo when you want to dcommit, or you have to live
> with the possibility of a dcommit failing because you don't actually
> have the most recent rev locally.
I don't see why this has to be the case. Surely, if the local git repo
can dcommit without races by importing new revisions from svn, the
local git repo could dcommit without races by importing new revisions
from svn via an intermediate git repo. This would require the
intermediate repo to import new revisions when it gets a pull request,
but surely that should be doable with a pre-pull hook?
> This ties a bit into the patch I sent a few months back to allow
> update hooks to change refs. I kind of ran out of spare time to
> iterate more on that back then, but the ultimate goal there was that
> you could interact only with the bridge repo, never directly with
> svn, and the bridge repo would dcommit for you when you pushed to
> it.
I guess that approach is what I'd really like to see, since that's the
only one that can guarantee that every git clone of the svn repository
is identical.
Furthermore, in this setup the clients wouldn't need to run git-svn at
all. Only the bridge would need it.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
