On Mon, 6 Apr 2009, Nicolas Sebrecht wrote:
On Sun, Apr 05, 2009 at 02:28:35PM -0700, david@xxxxxxx wrote:
guys, back off a little on telling the gentoo people to change.
Don't blame Git people, please. I currently am the only one here to
discuss that way and see a painful work coming at Gentoo.
Git people didn't discuss around thoses issues.
the
kernel developers don't split th kernel into 'core' 'drivers' etc pieces
just because some people only work on one area.
And you might notice that they don't provide a CVS access and actually
don't work around an unique shared repo. Also, you might notice that
keeping the history clean to assure the work on the kernel easier is not
an elementary issue.
these issues are completely seperate from the issue that the initial
poster asked about, which is that when someone tries to do a clone of the
repository the system wastes a lot of time creating a new pack.
the kernel has a central public repo, they could run the cvs server on
that and still keep the rest of the kernel development exactly the way it
is.
if they are currently planning for one central repo with everyone pushing
to it, I expect that they will change their workflow as they get used to
git, but that isn't going to address the problem in the tool.
just because some people only work on one area. I see the gentoo desire
to keep things in one repo as being something very similar.
That's why I think the gentoo desire is not very clean (don't be
affected). What I see is that in one hand you want a DSCM and on the
other hand you want to keep a central shared repo.
don't worry about this part of things, worry about why the server wastes
so many resources.
if this is really what's happening, other projects will suffer as well
(including the kernel, which has a very distributed workflow)
the problem here is a real one, if you have a large repo, git send-pack
will always generate a new pack, even if it doesn't need to (with the
extreme case being the the repo is fully packed)
What about the rsync solution given in this thread?
that may be a work-around for a situation where git just doesn't work, but
how do they prevent users from killing their server by trying to do a
normal git clone?
Daivd Lang
--
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