Re: [Groff] GNU Bazaar import of Groff

[Colin Watson]

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                                       address@hidden