[arch-users] Re: cvs <-> arch mirroring scripts

[arch-users] Re: cvs <-> arch mirroring scripts

[Miles Bader]

[Note I've re-expanded the CC, since I think this is a generally
interesting topic.]

Stefan Monnier <monnier@rum.cs.yale.edu> writes:
> For what it's worth, smerge-mode offers a "conflict resolver" for changelog
> files which works fairly well in my experience.

Hmmm, I'll look at it; I don't think I can use smerge though, as I want
to run this automatically in a script, and I'm not very comfortable
with using emacs in that situation...

> Or maybe you could follow a changelog-like convention in your arch commit
> log and then automatically generate the changelog text (and prepend it)
> before committing with CVS (after all, the changelog file is not needed
> for arch or svn where the commit log works just as well, contrary to CVS).

I could do that, though there are various issues to sort out:

 * Existing tools -- and habits -- support incrementally adding to the
   various ChangeLog files as one makes changes, and this style of
   creating changelog entries promotes writing them as one makes the
   changes rather than when committing, which I think is generally the
   best practice.

 * It's very useful to have all the ChangeLog entries at hand in an
   easily searchable file when one needs them, so _in general_ searching
   the archive is not a good way to access this information.

   In arch, I believe (...) all the commit log files are actually part of
   the working-directory (underneath {arch}), so maybe it's not as much
   of a problem as it would be with some other systems, but really one
   wants this info to be available even when exporting to other formats.

So here's a more detailed expansion of what you said:

  1. Have a script to run for commiting to an emacs arch branch (or even
     some sort of arch hook to do it automagically), which would take
     any changes to ChangeLog files, insert them into the commit log
     file, and revert the actual ChangeLog files.

     This has the problem that _any_ arch command that might examine/
     modify the ChangeLogs -- such as merging changes from another
     branch -- would need the ChangeLog changes to be reverted first,
     and then re-applied afterwards, so perhaps this isn't a very good
     method.

     Hmmm, how easy it it to override emacs' notion of which ChangeLog
     file to use?  If emacs in an arch tree always used a temporary
     (until-commit) file for all ChangeLog entries, ignoring the in-tree
     ChangeLogs, this would be simpler, e.g., `$tree_root/+commit-changelog'
     (to use Tom's file-naming convention).

  2. On branches, keep this info in the commit log files, not in the
     ChangeLog files.  This would mean that for recent changes in a
     branch, one would have to be aware of where the info is, but I
     think this is not that big a deal -- in my experience ChangeLogs
     are mostly useful for seeing what other people have changed, and
     for trying to find very old changes, so searching for recent
     changes in one's own branch should be much less common.

  3. As you described, re-add the commit logs into the ChangeLog files
     as part of the CVS synchronization step, avoiding most conflicts.

  4. Commit the updated ChangeLogs back to the arch `cvs-trunk' branch.
     So the commit logs would eventually become part of the ChangeLog
     files in arch too, just not immediately.

     In a future `all-arch' world, I guess you'd still need this step at
     some point; actually in that case, since CVS-synchronization is not
     a problem, the best time to do it might be when importing changes
     from private branches into the `trunk' branch; that way the
     ChangeLog update would be part of the same ChangeSet as the changes
     it describes.

Well, this is all a bit rambling, but do you have any more comments?

Thanks,

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: [arch-users] Re: cvs <-> arch mirroring scripts

[Tom Lord]

[complete aside but, starting tomorrow, the list formerly known as 

	arch-users@lists.fifthvision.net

 is now known as

	gnu-arch-users@gnu.org

 Sorry for any inconvenience.]


-t

[arch-users] Re: cvs <-> arch mirroring scripts

[Miles Bader]

BTW, I checked in my first two changesets from arch->CVS for emacs today:

I just did `tla update' in my, then generated a CVS log message from the
arch log, e.g.:

   tla cat-log miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14 | sed -n '/^Standard-date:/d;/^Date:/d;/^[^:]*:.*[^ ]/p;/^$/,$p' > /tmp/,l

Then committed the whole tree:

   cvs commit -F/tmp/,l

This generates CVS log entries like this:

   ----------------------------
   revision 1.43
   date: 2003/08/14 09:05:44;  author: miles;  state: Exp;  lines: +2 -2
   Revision: emacs--cvs-trunk--0--patch-14
   Archive: miles@gnu.org--gnu-2003
   Creator: Miles Bader <miles@gnu.org>
   Summary: Avoid .arch-ids dirs when making autoloads
   Modified-files: ./lisp/Makefile.in
   New-patches: miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14

   Avoid .arch-ids dirs when making autoloads
   ----------------------------

Which I think is nice, and gives you some useful info about which arch
changeset the change came from.

Note that the arch-changeset's author is included in the message, which
helps ameliorate the `single CVS checkin point' a bit.

I'm gonna try to make a script to do some of this, though at first it
will probably just abort if detects any hard things (like renames or
conflicts) and let the invoker deal with them.

The one case that I'm bit concerned about is the old standard --
ChangeLog files.  In the above changesets I actually forgot to update
the ChangeLog, so it wasn't an issue :-), but in general, I suppose it's
going to be necessary to resolve `trivial' ChangeLog conflicts
automatically.  Luckily, I think this is fairly easy -- just look for a
ChangeLog.rej file that contains only add-lines-at-the-beginning, and
translate it into text to prepend to the ChangeLog -- but I know people
have rejected such automated merging of ChangeLogs for CVS in the past;
anyone know more details?

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: [arch-users] Re: cvs <-> arch mirroring scripts

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Thu, 2003-08-14 at 19:35, Miles Bader wrote:
> BTW, I checked in my first two changesets from arch->CVS for emacs today:
> 
> I just did `tla update' in my, then generated a CVS log message from the
> arch log, e.g.:
> 
>    tla cat-log miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14 | sed -n '/^Standard-date:/d;/^Date:/d;/^[^:]*:.*[^ ]/p;/^$/,$p' > /tmp/,l


Rather than committing the entire tree, I use larch what-changed
combined with xargs to generate a list of added and delete files,
perform those cvs operations, then get the list of added U deleted U
altered files and use xargs again to cvs ci those files.

There are files in CVS, that aren't in arch, and should be in cvs (long
story - they are autoconf generated files) and that I don't want to
commit alterations to, back to CVS.

Cheers.
Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[arch-users] Re: cvs <-> arch mirroring scripts

[Miles Bader]

Robert Collins <rbcollins@cygwin.com> writes:
> Rather than committing the entire tree, I use larch what-changed
> combined with xargs to generate a list of added and delete files,
> perform those cvs operations, then get the list of added U deleted U
> altered files and use xargs again to cvs ci those files.
> 
> There are files in CVS, that aren't in arch, and should be in cvs (long
> story - they are autoconf generated files) and that I don't want to
> commit alterations to, back to CVS.

Hmmm, that's probably a better method -- I glossed over it in my
previous post, but I had to temporarily move lisp/subdirs.el out of the
tree to make CVS happy before committing!  I think your method would
solve this.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: cvs <-> arch mirroring scripts

[Richard Stallman]

    This generates CVS log entries like this:

       ----------------------------
       revision 1.43
       date: 2003/08/14 09:05:44;  author: miles;  state: Exp;  lines: +2 -2
       Revision: emacs--cvs-trunk--0--patch-14
       Archive: miles@gnu.org--gnu-2003
       Creator: Miles Bader <miles@gnu.org>
       Summary: Avoid .arch-ids dirs when making autoloads
       Modified-files: ./lisp/Makefile.in
       New-patches: miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14

That is 6 lines longer than normal.  The extra lines will make it
harder to scan the CVS log for relevant information.  Can you make
that any more compact?  Is all of it really necessary?

Re: cvs <-> arch mirroring scripts

[Rajesh Vaidheeswarran]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "Miles Bader" <miles@gnu.org>
Cc: <arch-users@lists.fifthvision.net>; <emacs-devel@gnu.org>
Sent: Sunday, August 17, 2003 1:29 PM
Subject: Re: cvs <-> arch mirroring scripts


>     This generates CVS log entries like this:
>
>        ----------------------------
>        revision 1.43
>        date: 2003/08/14 09:05:44;  author: miles;  state: Exp;  lines:
+2 -2
>        Revision: emacs--cvs-trunk--0--patch-14
>        Archive: miles@gnu.org--gnu-2003
>        Creator: Miles Bader <miles@gnu.org>
>        Summary: Avoid .arch-ids dirs when making autoloads
>        Modified-files: ./lisp/Makefile.in
>        New-patches: miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14
>
> That is 6 lines longer than normal.  The extra lines will make it
> harder to scan the CVS log for relevant information.  Can you make
> that any more compact?  Is all of it really necessary?

Another possibility would require a change to the cvs command line (harder
to justify to the wide world), but might be useful.

Adding a -L (long listing, since -l is already taken) flag to `cvs log' to
list lines that are marked as extensions.

Re: cvs <-> arch mirroring scripts

[Richard Stallman]

    > That is 6 lines longer than normal.  The extra lines will make it
    > harder to scan the CVS log for relevant information.  Can you make
    > that any more compact?  Is all of it really necessary?

    Another possibility would require a change to the cvs command line (harder
    to justify to the wide world), but might be useful.

    Adding a -L (long listing, since -l is already taken) flag to `cvs log' to
    list lines that are marked as extensions.

We could also add such a feature to C-x v l, which might be
more convenient than changing CVS.

[arch-users] Re: cvs <-> arch mirroring scripts

[Rajesh Vaidheeswarran]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "Rajesh Vaidheeswarran" <rv@gnu.org>
Cc: <arch-users@lists.fifthvision.net>; <emacs-devel@gnu.org>;
<miles@gnu.org>
Sent: Monday, August 18, 2003 3:15 PM
Subject: Re: cvs <-> arch mirroring scripts


>     > That is 6 lines longer than normal.  The extra lines will make it
>     > harder to scan the CVS log for relevant information.  Can you make
>     > that any more compact?  Is all of it really necessary?
>
>     Another possibility would require a change to the cvs command line
(harder
>     to justify to the wide world), but might be useful.
>
>     Adding a -L (long listing, since -l is already taken) flag to `cvs
log' to
>     list lines that are marked as extensions.
>
> We could also add such a feature to C-x v l, which might be
> more convenient than changing CVS.

If we decide to change, I'd rather that we change CVS, since many users
(including myself) may not use CVS from within emacs all the time..

rv