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