* [arch-users] Re: cvs <-> arch mirroring scripts [not found] <200308151543.h7FFhofE006354@rum.cs.yale.edu> @ 2003-08-16 2:30 ` Miles Bader 2003-08-16 2:43 ` Tom Lord 0 siblings, 1 reply; 6+ messages in thread From: Miles Bader @ 2003-08-16 2:30 UTC (permalink / raw) Cc: emacs-devel, arch-users [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_) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [arch-users] Re: cvs <-> arch mirroring scripts 2003-08-16 2:30 ` [arch-users] Re: cvs <-> arch mirroring scripts Miles Bader @ 2003-08-16 2:43 ` Tom Lord 0 siblings, 0 replies; 6+ messages in thread From: Tom Lord @ 2003-08-16 2:43 UTC (permalink / raw) Cc: monnier, emacs-devel, arch-users, gnu-arch-users [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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <1060744673.2522.27.camel@columbia>]
[parent not found: <buo65l2facg.fsf@mcspd15.ucom.lsi.nec.co.jp>]
[parent not found: <1060803518.28891.27.camel@columbia>]
* [arch-users] Re: cvs <-> arch mirroring scripts [not found] ` <1060803518.28891.27.camel@columbia> @ 2003-08-14 9:35 ` Miles Bader 2003-08-14 9:46 ` Robert Collins 2003-08-17 17:29 ` Richard Stallman 0 siblings, 2 replies; 6+ messages in thread From: Miles Bader @ 2003-08-14 9:35 UTC (permalink / raw) Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [arch-users] Re: cvs <-> arch mirroring scripts 2003-08-14 9:35 ` Miles Bader @ 2003-08-14 9:46 ` Robert Collins 2003-08-14 9:59 ` Miles Bader 2003-08-17 17:29 ` Richard Stallman 1 sibling, 1 reply; 6+ messages in thread From: Robert Collins @ 2003-08-14 9:46 UTC (permalink / raw) Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* [arch-users] Re: cvs <-> arch mirroring scripts 2003-08-14 9:46 ` Robert Collins @ 2003-08-14 9:59 ` Miles Bader 0 siblings, 0 replies; 6+ messages in thread From: Miles Bader @ 2003-08-14 9:59 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cvs <-> arch mirroring scripts 2003-08-14 9:35 ` Miles Bader 2003-08-14 9:46 ` Robert Collins @ 2003-08-17 17:29 ` Richard Stallman 2003-08-17 17:42 ` Rajesh Vaidheeswarran 1 sibling, 1 reply; 6+ messages in thread From: Richard Stallman @ 2003-08-17 17:29 UTC (permalink / raw) Cc: arch-users, emacs-devel 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cvs <-> arch mirroring scripts 2003-08-17 17:29 ` Richard Stallman @ 2003-08-17 17:42 ` Rajesh Vaidheeswarran 2003-08-18 19:15 ` Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Rajesh Vaidheeswarran @ 2003-08-17 17:42 UTC (permalink / raw) Cc: arch-users, emacs-devel ----- 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cvs <-> arch mirroring scripts 2003-08-17 17:42 ` Rajesh Vaidheeswarran @ 2003-08-18 19:15 ` Richard Stallman 2003-08-19 14:38 ` [arch-users] " Rajesh Vaidheeswarran 0 siblings, 1 reply; 6+ messages in thread From: Richard Stallman @ 2003-08-18 19:15 UTC (permalink / raw) Cc: arch-users, emacs-devel, miles > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [arch-users] Re: cvs <-> arch mirroring scripts 2003-08-18 19:15 ` Richard Stallman @ 2003-08-19 14:38 ` Rajesh Vaidheeswarran 0 siblings, 0 replies; 6+ messages in thread From: Rajesh Vaidheeswarran @ 2003-08-19 14:38 UTC (permalink / raw) Cc: arch-users, emacs-devel, miles ----- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-08-19 14:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <200308151543.h7FFhofE006354@rum.cs.yale.edu> 2003-08-16 2:30 ` [arch-users] Re: cvs <-> arch mirroring scripts Miles Bader 2003-08-16 2:43 ` Tom Lord [not found] <1060744673.2522.27.camel@columbia> [not found] ` <buo65l2facg.fsf@mcspd15.ucom.lsi.nec.co.jp> [not found] ` <1060803518.28891.27.camel@columbia> 2003-08-14 9:35 ` Miles Bader 2003-08-14 9:46 ` Robert Collins 2003-08-14 9:59 ` Miles Bader 2003-08-17 17:29 ` Richard Stallman 2003-08-17 17:42 ` Rajesh Vaidheeswarran 2003-08-18 19:15 ` Richard Stallman 2003-08-19 14:38 ` [arch-users] " Rajesh Vaidheeswarran
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.