On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote: > On Tuesday 20 October 2009, Zach Welch wrote: > > > > > - From time T+2 and later, everyone will want to get new clones > > > of that repository. I'll send out an email announcing this, > > > presumably as a followup on this thread. > > Actually, it turns out that I may be able to avoid that > step ... leave the old stuff in the repository, from which > it will get garbage collected in a few weeks. There would > be an advantage for anyone who has a private branch; it'll > be easier to bring it up to date. The disadvantage will be > that until that GC happens, HTTP clones will still need to > incur the costs of larger-than-desirable fetches. > > I'm not sure yet if I'll go that route. It'd be easier on > current clients, if I understand things right, which is why > I sort of like that notion: just "git pull", no need to > make new clones.
I agree that this might be a better migration path, since it provides better continuity of service. I had been thinking about pulling the new repository into the old to rebase my branches, so I had started to postulate a similar strategy might be feasible. If we go this route, would we even need to expose an '-old' GIT tree? All of its content still exists in the original Subversion repository; we lose nothing by dropping it and gain nothing by keeping it, right? Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
