Jon Smirl wrote: > On 10/14/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> * It would be nice to have tool to exchange commits between SCM and CVS, >> be it like Tailor/git-svn, or via incremental import and exporting >> commits to CVS like git-cvsexportcommit. This would ease changing SCM, >> as both new SCM and CVS could be deployed in parallel, for a short time >> of course. > > From what Brendan wrote they are looking to continue 1.9 in CVS and > start 2.0 in a new SCM. This pretty much mandates tracking CVS into > the new SCM for a long period of time. Possibly as much as two years. > There does not appear to be a need to push 2.0 back into CVS. That of course limits what we can do in 1.9 to what CVS supports. > > * It would be nice to have CVS emulation like git-cvsserver, so users > > accustomed to CVS could still use it. > > This can also solve some of the problems with Windows support. Well, git-cvsserver (perhaps with some improvements) could also serve as CVS server for 1.9. > > 4. Good support for _large_ project, with large history. Namely, that > > developer wouldn't need to download many megabytes and/or wouldn't need > > megabytes of working area. How that is solved, be it partial checkouts, > > lazy/shallow/sparse clone, subprojects, splitting into > > projects/repositories and having some superproject or build-time > > superproject, splitting repository into current and historical... that of > > course depends on SCM. > > git has issues here. The smallest Mozilla download we have built so > far is 450MB for the initial checkout. One way to reduce repository size would be to split fairly independent subprojects (inependent = independently testable) into separate repositories, and perhaps use some kind of "super-repository" (common repository) to join all the project in one single entity. The split can be done using git-splitrepo (or something like that) which was posted on git mailing list (most probably by some member of X.Org), or just cg-admin-rewritehist. While at it we could split repository into current work and historical repo; and clean up current work repository from the cruft accumulated (e.g. dead branches, broken tags etc.). Another way is to use grafts. Linux kernel has it's current repository (starting somewhere 2.6.x), and it's historical repository. I don't remember how they arrived at it (and don't want to check KernelTrap articles), if the seed for current work repository was simply project import at some state, or (very slow) import of BitKeeper history. But if I remember correctly it was born split. You can join both repositories into one (wrt. log and diff for example) using grafts. I'm not sure what happens if you pull from repository which has graft file "cauterizing" history; would you get graft file and history up to cutoff point? What would happen if your repository, repository you pull to has cauterization graft file; would it get cut history? Of course the problem (and the source of proposal and troubles with implementing of shallow/sparse/lazy clone) lies if someone branches (in public repo) from below cutoff point. But that is a matter of policy. But it is true that the size of Mozilla repository is a challenge. BTW. do you perchance know how other SCM dels with the repository of that size? -- Jakub Narebski ShadeHawk on #git Poland - 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