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

[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

Re: cvs <-> arch mirroring scripts

[Richard Stallman]

    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..

Overall it would be cleaner to change CVS.  However, CVS is not a GNU
package and I am not sure how its maintenance is going these days.
Does anyone know?  We may find that the only way to get a change
installed is to install it in Emacs.

Could people design a spec for the change?  Then I will send it to
bug-cvs.

Re: cvs <-> arch mirroring scripts

[dhruva]

On Wed, 20 Aug 2003 13:23:23 -0400, "Richard Stallman" <rms@gnu.org>
said:
>     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..
> 
> Overall it would be cleaner to change CVS.  However, CVS is not a GNU
> package and I am not sure how its maintenance is going these days.
> Does anyone know?  We may find that the only way to get a change
> installed is to install it in Emacs.
> 
> Could people design a spec for the change?  Then I will send it to
> bug-cvs.

 One feature I am looking for (and am quite sure there are many other
 users out there) is TUNNELING capability or access through firewall. It
 is not a enhancement to the behaviour of CVS but more a desired feature
 to allow people like me behind firewall.
 I have used ProxyTunnel to access CVS, but I would prefer CVS to handle
 it instead of me having to depend on another tool.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Web: http://schemer.fateback.com/

Re: cvs <-> arch mirroring scripts

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>        ----------------------------
>        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?

Hmmm, well lets see; here are the extra added lines:

  Revision:     Identifies the arch changeset the change came from;
                I think this is very useful information and should be
                kept.

  Archive:      This is really part of the changeset name; it could be
                put into the Revision: header I think.

  Creator:      This is redundant in this case, but since CVS checkins
                from arch probably will occur from a single `gateway user'
                so that it's necessary to record the _actual_ author
                somewhere.

                This field might be eliminated for cases where both
                names are the same, or if there were a way to make CVS
                record a different author than the person who did the
                checkin (I've heard of CVS patches to allow this, but I
                think that implementation only works with a local CVS
                server).

  Summary:      This is actually part of the description; maybe it
                should be moved to be directly in front of the rest of
                the description, or even made part of the description.

  Modified-files:  I think this is useful information, but it could be
                elided in the case where only one file was part of the
                changeset.

  New-patches:  This is mainly useful to arch, so I think it could be
                removed (it can always be reconstructed by looking up
                the arch changeset using the information in the
                Revision: header).

So a typical one-file changeset might become something like this:

        revision 1.43
        date: 2003/08/14 09:05:44;  author: arch;  state: Exp;  lines: +2 -2
        Revision: miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-14
        Creator: Miles Bader <miles@gnu.org>

        Avoid .arch-ids dirs when making autoloads

A bigger changeset would add the Modified-files: header back in, but
since the DESCRIPTION would likely be much longer too, it's probably
less of an issue, and I think being able to see exactly which files
were modifies is useful.  E.g.:

        revision X.Y
        date: 2003/08/14 09:05:44;  author: arch;  state: Exp;  lines: +2 -2
        Revision: miles@gnu.org--gnu-2003/emacs--cvs-trunk--0--patch-73
        Creator: Miles Bader <miles@gnu.org>
        Modified-files: lisp/file2.el src/file1.c src/file2.c

        SUMMARY

        LONG DESCRIPTION
        ...

This seems pretty readable to me; what do you think?

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://mail.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

Re: cvs <-> arch mirroring scripts

[Richard Stallman]

      Revision:     Identifies the arch changeset the change came from;
		    I think this is very useful information and should be
		    kept.

How is that useful to CVS users like me?

      Archive:      This is really part of the changeset name; it could be
		    put into the Revision: header I think.

      Creator:      This is redundant in this case, but since CVS checkins
		    from arch probably will occur from a single `gateway user'
		    so that it's necessary to record the _actual_ author
		    somewhere.

I see two possibilities:

1. We should think of this person as the one who checked in the
change.  If so, the info is useful but the CVS checkin user info is
useless.  This name should go in the CVS checkin user name, not in a
separate "Creator" field.

2. We should not think of this person as the one who checked in the change.
Then the info is useless.

Which of these is appropriate depends on how the arch checkin setup
will be used.  Will people need to have Savannah write-access to Emacs
in order to enter changes in the arch repository?  If so, I think
we should do #1.

Re: cvs <-> arch mirroring scripts

[Miles Bader]

On Mon, Aug 18, 2003 at 03:16:06PM -0400, Richard Stallman wrote:
>       Revision:     Identifies the arch changeset the change came from;
> 		    I think this is very useful information and should be
> 		    kept.
> 
> How is that useful to CVS users like me?

Because (1) it identifies which arch revision the change came from, which
allows you to go back to the arch changeset to get more info if you need it,
(2) it helps identify the change as part of a changeset along with other
files, which is a generally useful concept even if not supported by the
mechanics of CVS.

You may not immediately need this info in your everyday log browsing, but
that doesnt mean it's not useful.  However, it does suggest that maybe the
idea of adding output-filtering to vc.el's C-v l command is good.  That way
you can strip out this stuff that may interfere with casual browsing, but
it's available in case you ever _do_ want it.

>       Creator:      This is redundant in this case, but since CVS checkins
> 		    from arch probably will occur from a single `gateway user'
> 		    so that it's necessary to record the _actual_ author
> 		    somewhere.
> 
> 1. We should think of this person as the one who checked in the
> change.  If so, the info is useful but the CVS checkin user info is
> useless.  This name should go in the CVS checkin user name, not in a
> separate "Creator" field.

This is true.  I think modifying the `cvs' client to do such a
substitution would be a pain, but maybe this is another thing that vc.el
could easily do.

[Also note that this field could be used in other non-arch-related cases,
when for some reason one person checks in a change for another]

It looks to me like the best solution is simply to hack vc.el a bit as
previously described.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://mail.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

Re: cvs <-> arch mirroring scripts

[Richard Stallman]

    > How is that useful to CVS users like me?

    Because (1) it identifies which arch revision the change came from, which
    allows you to go back to the arch changeset to get more info if you need it,
    (2) it helps identify the change as part of a changeset along with other
    files, which is a generally useful concept even if not supported by the
    mechanics of CVS.

That's not particularly useful for me.

    You may not immediately need this info in your everyday log browsing, but
    that doesnt mean it's not useful.  However, it does suggest that maybe the
    idea of adding output-filtering to vc.el's C-v l command is good.  That way
    you can strip out this stuff that may interfere with casual browsing, but
    it's available in case you ever _do_ want it.

Ok, let's try to do it that way.

    > 1. We should think of this person as the one who checked in the
    > change.  If so, the info is useful but the CVS checkin user info is
    > useless.  This name should go in the CVS checkin user name, not in a
    > separate "Creator" field.

    This is true.  I think modifying the `cvs' client to do such a
    substitution would be a pain, but maybe this is another thing that vc.el
    could easily do.

Ok.

    [Also note that this field could be used in other non-arch-related cases,
    when for some reason one person checks in a change for another]


That would be inconsistent.  If in arch changes the person in the
Creator field is considered the one who checked in the change, then we
should not use the Creator field to indicate the real author in other
cases.

Currently what we do is put the real author in ChangeLog, not in the
CVS log entry.  That seems to work well and I see no reason to change it.

[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