Gentoo Archives: gentoo-scm

From: Mike Auty <ikelos@g.o>
To: Donnie Berkholz <dberkholz@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Status of the project?
Date: Mon, 26 Jan 2009 20:05:25
In Reply to: Re: [gentoo-scm] Status of the project? by Donnie Berkholz
Hash: SHA1

Donnie Berkholz wrote:
> Wouldn't it be great if Mike could simple merge his package into the > tree without losing all that history? This would make git-bisect > meaningful, instead of bringing in a huge collection of unrelated > changes in a single commit.
I don't think "huge collection of unrelated changes in a single commit" fits for either 1 repo/tree or 1 repo/package. In either case I'd expect a single commit to be a single set of relevant changes, or have I not understood what you meant? In the 1 repo/tree, I'd only expect to see commits that spanned package directories if they were in some way relevant (changing all the license for something like gst-plugins-*)... It might be worth playing around with --depth? "Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches." It's not clear whether it can pull/fetch/update from upstream, and it's not clear how easy it would be to re-integrate. It might also still end up pulling 100+ Mb for a full portage checkout, so this may not end up being a feasible solution, but it's worth a look. The other option is some form of git-split tool used at fork time to strip everything down to just the required files. We can import from either type of repo using patchsets if necessary, but I don't see it as being a particularly common scenario. My larger concern with 1 repo/package is the more likely situation where developer Mike is trying to deal with a bug, and eventually spots that the user is using cat/foo-1.0 from commit a83b28d, only there is no commit a83b28d in the package repo, because the user's using a fork in his main tree. It's just cost the developer 20 minutes looking for all the possible answers, then finally checking git-log and eventually finding there's no commit, all because it's not easy to determine whether everybody's working on the same page. That's why there's overlay names all over the portage output in recent versions if you're building a non-main-tree package. If you can solve the management issues, I still like the idea (a 600+ Mb repo is still horribly huge, and I'd sooner not have to lug that around), but as I mentioned in my earlier email, there's a lot of unanswered questions as to how it would work...
> Thanks for the pointer to that thread, I hadn't seen it!
No probs! 5:)
> I don't really think this matters. At some point we'll want to cut off > CVS access. Whether we have git in place on only a test repo or on the > gold repo before this cutoff doesn't seem like it would be that > relevant.
Fair enough, it just sounded like people wanted to get git as the main repo before CVS was cut off, and if we're gonna do that, someone should locally test the cvsserver to make sure there's no issues...
> Just curious why you want to post it as a separate repo? If you come up > with a magic repacking command, just push your new commits and ask Robin > to run a repack.
I wasn't intending to, it was just if people had specific requests. I'm also hoping to keep it more up to date (the one on exp/gentoo-x86.git doesn't seem to have had a history update in a few months). Unfortunately since I'm using cvsimport rather than cvs2svn, the log messages produced are likely to be different. Since they're a part of the commit, it won't be a case of simply commiting my changes, since all the hashes will be different. However, as I said, it's mostly a little local experiment, and I'd only post it if there were requests...
> I expect Robin would want to set you up on git.overlays.g.o if you > really want to post it. He got a little annoyed with me when I put mine > on dev.g.o.
Yeah, fair enough. I'd clear it with infra before dumping anything that big anywhere on *.g.o ... 5;) Mike 5:) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl+F4AACgkQu7rWomwgFXotAwCfVMsKjpZABK5w+CcqMbf6o4LX Cg0AmwQ8VhrQN3FWOMHXlqegHJ3NTgyX =rvhl -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-scm] Status of the project? Donnie Berkholz <dberkholz@g.o>