Norbert Koch <viteno(a)xemacs.org> writes:
* "Stephen J. Turnbull" <stephen(a)xemacs.org>:
> That's correct. It is not obvious to me that recursive commit is
> desirable unless Norbert *never* makes local changes of his own in
> packages in that tree[2], only changes related to releases and build
> infrastructure. The point is that he needs to pull in the package
> repo anyway, and he needs to do the ChangeLog and Makefile updates
> there, so he may as well commit there too. Then back up to the top
> level, make any needed changes there, commit, and push.
Hmm, how should I commit the Makefile and ChangeLog changes I make to
the packages? Right now after I've uploaded the new set I get
Norbert, there's something really strange about your workflow. I have
trouble understanding because I don't know what exactly you did, and
what "uploaded" and "new set" mean.
nk@vserv:test% hg st -qS
M xemacs-packages/Sun/.hgtags
[...]
because these changes have been committed locally.
And what does "these changes" mean?
IMHO, what you should do is very simple, depending on the situation:
1. Somebody makes a change to a package and you want to include that in
the global xemacs-packages hierarchy.
You do:
cd xemacs-packages/<package>
hg pull -u
cd ../..
hg commit -m "Update package X."
2. You want to update a package:
cd xemacs-packages/<package>
... edit ...
hg commit -m "<log message>"
2.1 You then want to include that update in the global xemacs-packages
hierarchy:
cd ../..
hg commit -m "Update package X."
3. You want to update something in xemacs-packages itself
... edit ...
hg commit -m "<log message>"
Does that help at all? How did your procedure differ?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta