On Mon, Feb 16, 2009 at 08:04:18AM +0100, Werner LEMBERG wrote: > Colin Watson wrote: > > I thought some of you might be interested to know that there's now a > > rolling import of Groff's CVS repository into GNU Bazaar > > (http://bazaar-vcs.org/), thanks to Michael Hudson and others at my > > employer, Canonical. > > Nice! On the other hand, I would have used git...
Oh, that's a shame, although obviously it's your decision as primary committer. Quite apart from my employment affiliations, I find git's user interface so poorly designed that I generally can't tolerate using it for very long, so anyone wanting a git import will have to do it themselves. A bzr import is useful for me anyway, so the effort isn't wasted. > > Sorry about the "Filler changeset" cruft occupying a block of > > revisions near the end of the branch. This is because several files > > in CVS have their default branch set to something other than MAIN, > > probably due to use of vendor branches, and this is how cscvs keeps > > track of those. > > This is indeed very ugly. > > > I don't think it'll create any significant number more of them as > > time goes on - probably none, if vendor branches aren't used again > > and if I've understood cscvs' innards correctly. > > Honestly, I can't remember that I've ever used a vendor branch! See e.g. src/libs/libxutil/xmalloc.c which 'cvs log' says is on "branch: 1.1.1" - usually a sign of the use of 'cvs import' or similar. The same thing shows up for imports of mom, code from Eric, etc. It's one of those warts in CVS that often seems like a good idea at the time but in fact produces very weird repositories; every time I've used 'cvs import' I've regretted it later. > Additionally, I can't recognize the usefulness of the various entries. > For example, what's the difference between rev. 1859 and 1857? Both > appear to be empty. Are you sure that this isn't a bug in the > conversion program? It's one revision per affected file. It could well be a bug in the conversion program (or at least the lack of a feature to handle this sort of thing some better way; it does have to track it somehow when a file is on a branch other than MAIN, since if that changes the effective contents of the repository could change without there being anything that looks like a changeset expressing the change), although from the sound of things it is also an unintended repository layout. :-) If these files aren't actually supposed to have their default branch set to 1.1.1 (essentially equivalent to a vendor branch), then perhaps you could fix it in the repository? Running 'cvs admin -b' on each affected file ought to do it. You'd probably want to compare checkouts before and after to make sure this causes no textual differences, but I don't think it should. I imagine I could then persuade the Launchpad operators to nuke the current import and run it again, which should get rid of the filler changesets. Here's a complete list: contrib/eqn2graph/.cvsignore contrib/grap2graph/.cvsignore contrib/mom/mom.tmac font/devX100-12/DESC font/devX100-12/Makefile.sub font/devX100/DESC font/devX100/Makefile.sub font/devX75-12/DESC font/devX75-12/Makefile.sub font/devX75/DESC font/devX75/Makefile.sub font/devascii/DESC.proto font/devcp1047/DESC.proto font/devdvi/generate/msbm.map font/devlatin1/DESC.proto font/devlbp/DESC.in font/devlj4/DESC.in font/devps/DESC.in font/devps/psstrip.sed src/devices/grops/psfig.diff src/devices/grotty/TODO src/devices/xditview/.cvsignore src/devices/xditview/DESC.in src/devices/xditview/Dvi.h src/devices/xditview/FontMap src/devices/xditview/Menu.h src/devices/xditview/device.c src/devices/xditview/device.h src/devices/xditview/draw.c src/devices/xditview/font.c src/devices/xditview/gray1.bm src/devices/xditview/gray2.bm src/devices/xditview/gray3.bm src/devices/xditview/gray4.bm src/devices/xditview/gray5.bm src/devices/xditview/gray6.bm src/devices/xditview/gray7.bm src/devices/xditview/gray8.bm src/devices/xditview/lex.c src/devices/xditview/page.c src/devices/xditview/parse.c src/devices/xditview/xdit.bm src/devices/xditview/xdit_mask.bm src/libs/libxutil/DviChar.c src/libs/libxutil/XFontName.c src/libs/libxutil/xmalloc.c src/preproc/eqn/TODO src/preproc/refer/TODO src/preproc/soelim/TODO src/utils/indxbib/eign tmac/man.ultrix Indeed, this matches the number of annoying filler changesets that cscvs generated. > > Feel free to make use of this import as you wish, including > > mirroring the branch elsewhere, or even switching to it for Groff > > development if you'd like :-) (in which case I guess you'd want to > > host it on Savannah). > > As said earlier, I prefer git, and reading the emacs mailing list, > there are (still) good reasons for that. Is there already a GNU bzr > server? I know that git is already supported at gnu.org. Savannah has some support for bzr and there's a small collection of branches hosted there already, although unfortunately it does not seem to be available in the web interface yet. I think it's just a matter of a support request to enable it for a project. See e.g.: https://savannah.gnu.org/support/?106417 https://savannah.gnu.org/support/?106612 (Obviously the latter is quite involved!) I've filed https://savannah.gnu.org/support/index.php?106642 for man-db now, so I'll see if this procedure works ... Thanks, -- Colin Watson [[email protected]]
