Re: ChangeLog entries
Hi, On Tue, 2003-08-19 at 00:54, Brian Jones wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > I would certainly made this into three commits but would have just used > > the given separate ChangeLog entries as shown since eacht entry is > > clearly a group of changes that is related. > > My typical usage is: > > 1) Make vast sweeping changes > 2) cd classpath > 3) cvs ci . > > I don't really like that this puts changes to other files in the log > of every file... but it's the easy and simple way not to screw up. > More helpful if cvs grok'd ChangeLog entries and fixed the log as you > go... but oh well. Should I adjust? No, I think this is fine. As long as the "vast sweeping changes" are related to each other. If they change completely different things in the code then it makes sense to copy your classpath cvs checkout working directory and work/test these thing separately so they can easily be committed independently from each other. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, 2003-08-18 at 08:05, Sascha Brawer wrote: > > Here's a question about ChangeLog entries: Would it make sense to have > > separate commits (and thus ChangeLog entries) for unrelated changes? > > Yes for completely unrelated changes they should be committed seperately > (especially when doing a formatting change and a logical change, do them > in two separate commits). But do try to do a commit of as much > things/files that are done at the same time which can logically be seen > as part of the same change/cleanup etc. > > > The guile guidelines do not mention this, but I personally think it can > > be rather unpleasant to sift through dozens of irrelevant lines when > > trying to find out what has happened to a file. > > > > For example, the attached log message does not seem to be very helpful. > > (The author is omitted in order to not pick on anybody in particular). > > IMHO, such bulk commits make it harder to track changes. > > The three log messages that you quote seem logically grouped together. > O, I see you mean that they are actually one commit. > Then it would have made sense to just use the New files/Regenerate entry > since logically it was just the adding of a bunch of new files (that > they were edited offline a couple of times isn't really reflected in out > CVS so it doesn't have to to be mentioned (except maybe if it comes from > resyncing with another tree, like libgcj, then it is a good idea to add > all relevant changes that were done in the other tree to our ChangeLog). > I would certainly made this into three commits but would have just used > the given separate ChangeLog entries as shown since eacht entry is > clearly a group of changes that is related. My typical usage is: 1) Make vast sweeping changes 2) cd classpath 3) cvs ci . I don't really like that this puts changes to other files in the log of every file... but it's the easy and simple way not to screw up. More helpful if cvs grok'd ChangeLog entries and fixed the log as you go... but oh well. Should I adjust? Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Hi, On Mon, 2003-08-18 at 08:05, Sascha Brawer wrote: > Here's a question about ChangeLog entries: Would it make sense to have > separate commits (and thus ChangeLog entries) for unrelated changes? Yes for completely unrelated changes they should be committed seperately (especially when doing a formatting change and a logical change, do them in two separate commits). But do try to do a commit of as much things/files that are done at the same time which can logically be seen as part of the same change/cleanup etc. > The guile guidelines do not mention this, but I personally think it can > be rather unpleasant to sift through dozens of irrelevant lines when > trying to find out what has happened to a file. > > For example, the attached log message does not seem to be very helpful. > (The author is omitted in order to not pick on anybody in particular). > IMHO, such bulk commits make it harder to track changes. The three log messages that you quote seem logically grouped together. O, I see you mean that they are actually one commit. Then it would have made sense to just use the New files/Regenerate entry since logically it was just the adding of a bunch of new files (that they were edited offline a couple of times isn't really reflected in out CVS so it doesn't have to to be mentioned (except maybe if it comes from resyncing with another tree, like libgcj, then it is a good idea to add all relevant changes that were done in the other tree to our ChangeLog). I would certainly made this into three commits but would have just used the given separate ChangeLog entries as shown since eacht entry is clearly a group of changes that is related. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Mark Wielaard <[EMAIL PROTECTED]> wrote on Wed, 13 Aug 2003 01:05:31 +0200: >I would really like everybody to follow the ChangeLog entry guidelines >given in: >http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html Here's a question about ChangeLog entries: Would it make sense to have separate commits (and thus ChangeLog entries) for unrelated changes? The guile guidelines do not mention this, but I personally think it can be rather unpleasant to sift through dozens of irrelevant lines when trying to find out what has happened to a file. For example, the attached log message does not seem to be very helpful. (The author is omitted in order to not pick on anybody in particular). IMHO, such bulk commits make it harder to track changes. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ % cvs log java/awt/font/GlyphVector.java [...] 2003-02-17 [...] * java/awt/dnd/DragSourceContext.java (addDragSourceListener): Added documentation. * java/awt/dnd/DragSourceDragEvent.java (serialVersionUID): New member variable. (getDropAction): Reformated. * java/awt/dnd/DragSourceDropEvent.java (serialVersionUID): New member variable. (dropSuccess): Renamed from success for serialization issues. * java/awt/dnd/DragSourceEvent.java (serialVersionUID): New member variable. * java/awt/dnd/DropTarget.java (serialVersionUID): New member variable. (DropTarget): Implemented, documentation reworked. (setComponent): Documentation added. (getComponent): Documentation added. (setDefaultActions): Documentation added. (getDefaultActions): Documentation added. (addDropTargetListener): Documentation added. * java/awt/dnd/DropTargetContext.java (DropTargetContext): Documentation added. (TransferableProxy.TransferableProxy): New method. (dropComplete): Fixed documentation. (getTransferable): Fixed documentation. (createTransferableProxy): Implemented. * java/awt/dnd/DropTargetDragEvent.java (DropTargetDragEvent): Documentation added. (serialVersionUID): New member variable. (DropTargetDragEvent): Throw exceptions, documentation added. (acceptDrag): Implemented. (getCurrentDataFlavors): Implemented.3yy (getCurrentDataFlavorsAsList): Implemented. (isDataFlavorSupported): Implemented. (rejectDrag): Implemented. * java/awt/dnd/DropTargetDropEvent.java (DropTargetDropEvent): Documentation added. (serialVersionUID): New member variable. (actions): Renamed from srcActions for serialization issues. (isLocalTx): Renamed from isLocalTx for serialization issues. (DropTargetDropEvent): New implementation, throw exceptions, documentation added. (getCurrentDataFlavors): Implemented. (getCurrentDataFlavorsAsList): Implemented. (isDataFlavorSupported): Implemented. (getSourceActions): Implemented. (getDropAction): Implemented. (getTransferable): Implemented. (acceptDrop): Implemented. (rejectDrop): Implemented. * java/awt/dnd/DropTargetListener.java (drop): Fixed documentation. * java/awt/dnd/MouseDragGestureRecognizer.java (MouseDragGestureRecognizer): Documentation added. 2003-02-17 [...] * java/awt/font/FontRenderContext.java, java/awt/font/ShapeGraphicAttribute.java, java/awt/font/MultipleMaster.java, java/awt/font/TransformAttribute.java, java/awt/font/GlyphJustificationInfo.java, java/awt/font/LineBreakMeasurer.java, java/awt/font/TextMeasurer.java, java/awt/font/TextLayout.java, java/awt/font/LineMetrics.java, java/awt/font/TextAttribute.java, java/awt/font/GlyphMetrics.java, java/awt/font/OpenType.java, java/awt/font/GlyphVector.java, java/awt/font/GraphicAttribute.java, java/awt/font/ImageGraphicAttribute.java, java/awt/font/NumericShaper.java: New files. * Makefile.am (awt_java_source_files): Added the following files: java/awt/font/FontRenderContext.java java/awt/font/ShapeGraphicAttribute.java java/awt/font/MultipleMaster.java java/awt/font/TransformAttribute.java java/awt/font/GlyphJustificationInfo.java java/awt/font/LineBreakMeasurer.java java/awt/font/TextMeasurer.java java/awt/font/TextLayout.java java/awt/font/LineMetrics.java java/awt/font/TextAttribute.java java/awt/font/GlyphMetrics.java java/awt/font/OpenType.java java/awt/font/GlyphVector.java java/awt/font/GraphicAttribute.java java/awt/font/ImageGraphicAttribute.java java/awt/font/NumericShaper.java * Makefile.in: Regenerated. 2003-02-17
Re: ChangeLog entries when merging things back from libgcj
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 14. Juli 2003 09:46 schrieb Mark Wielaard: > Hi, > > On Mon, 2003-07-14 at 07:50, Michael Koch wrote: > > * java/net/ServerSocket.java, > > java/net/Socket.java: New versions from libgcj. > > If possible I would like to see the original libgcj ChangeLog entry > when things get merged back into Classpath from libgcj. > > * java/net/ServerSocket.java > (setChannel): New method. > * java/net/Socket.java > (setChannel): New method. > > Is much more descriptive then the above. Sorry to make you troubles. Will do this in the future. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/EnRPWSOgCCdjSDsRAlynAJ9jOmnS1CldpRnHy6peT3uOlf2QfwCfX4j1 VmJwnjVOCiw71hz/f0MoaLU= =rlnd -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
