[libvirt] Switch from CVS to GIT is done

Daniel Veillard veillard at redhat.com
Mon Jul 6 14:19:06 UTC 2009


On Mon, Jul 06, 2009 at 03:41:34PM +0200, Jim Meyering wrote:
> Mark McLoughlin wrote:
> > On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote:
> >> Thanks to Jim Meyering we now have a new git repository, I deprecated the
> >> CVS repository, it's read only, you should still be able to keep it
> >> around to make patches for a few weeks if needed.
> >>   The new repo is at:
> >>     http://libvirt.org/git/?p=libvirt.git;a=summary
> >
> > Cool stuff!
> >
> > Any thoughts on what to do about ChangeLog?
> >
> > As an example of a sensible plan, GNOME dropped ChangeLog but some
> > modules still generate a ChangeLog for tarball releases. See here:
> >
> >   http://live.gnome.org/Git/ChangeLog
> 
> +1
> 
> I stopped maintaining-in-VC the ChangeLog file for GNU coreutils, too.
> However, a usable ChangeLog file still appears in each release tarball.
> It's generated at "make dist" time from commit logs via this rule from
> Makefile.am:
> 
> gen_start_date = 2008-02-08
> .PHONY: gen-ChangeLog
> gen-ChangeLog:
> 	if test -d .git; then						\
> 	  $(top_srcdir)/build-aux/gitlog-to-changelog			\
> 	    --since=$(gen_start_date) > $(distdir)/cl-t;		\
> 	  rm -f $(distdir)/ChangeLog;					\
> 	  mv $(distdir)/cl-t $(distdir)/ChangeLog;			\
> 	fi
> 
> If you want to continue using a version-controlled ChangeLog file,
> you'll definitely want to start using this tool from gnulib (just build
> it and install it in your path, following instructions in the C file):
> http://git.sv.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c
> It helps you avoid almost all ChangeLog-related conflicts.
> 
> The alternative (no vc'd ChangeLog file) is to generate it from commit
> logs.  That's what I do in coreutils, even though conflicts are no
> longer much of an issue, because I don't like having to keep ChangeLog
> and commit-log in sync with duplicate info.

  yeah, I think moving ChangeLog to ChangeLog.CVS and generating the
logs starting from today at "make dist" time is probably the best, it
will avoid copying over redundant informations. On the other hand we
should try to keep the git log output coherent with the previous format.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list