The workflow I'm looking for is something like svn/perforce changelists. That way I could have multiple unrelated changes coexisting in the same checkout. An example of this is what we use on Chromium: gcl.py (see the latest version at http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/gcl.py?view=markup). It allows you to create a changelist and associate a description and a list of files/directory changes with it). The basic usage is that "gcl change CHANGENAME" pops up a text file in the default editor where a description can be entered. By moving filenames from two sections below it, the developer controls which modified files are in this changelist. Operations such as "gcl upload CHANGENAME" (upload to Rietveld) work on the group of files at the same time (also things like gcl diff/commit/revert). The nice thing about it that on such large codebases, developers will often have unrelated changes, and this avoids having to unapply/apply frequently.
On Fri, Jul 10, 2009 at 5:57 PM, David Kilzer <ddkil...@webkit.org> wrote: > Quilt? <http://savannah.nongnu.org/projects/quilt> > > What workflow are you trying to accomplish? I'm not sure I understand what > a "changelist" is in this context and how bugzilla-tool would support them. > > Dave > > > > *From:* John Abd-El-Malek <j...@google.com> > *To:* Ojan Vafai <o...@chromium.org> > *Cc:* WebKit Development <webkit-dev@lists.webkit.org>; Mark Rowe < > mr...@apple.com> > *Sent:* Friday, July 10, 2009 5:11:53 PM > *Subject:* Re: [webkit-dev] Changes to prepare-ChangeLog > > To add another tangent to this thread: one thing I don't like about > ChangeLog files is that they make it impossible to have multiple concurrent > changes in the same checkout. Yes I know that some people use git to get > around this, while others use the svn-apply/svn-unapply scripts. But I feel > these are just workarounds to get around limitations of the current tools. > We should fix the tools instead. If we don't require to change one central > file for each change, then bugzilla-tool can be modified to support > changelists. > > On Thu, Jul 9, 2009 at 1:45 PM, Ojan Vafai <o...@chromium.org> wrote: > >> While having consistency in changelog descriptions is nice, I'm not sure >> we need to explicitly deal with the case of having multiple authors or >> multiple bugs for a change. Those are rare enough situations that it's fine >> for people to include that information however they want. >> Or, if you don't agree with me, we can at least make those a separate >> discussion. It would be nice if this discussion could focus on what goes in >> the default text of a changelog description. >> >> The original goal here was to reduce the number of patches that get r-'ed >> for unnecessary changelog errors. Multiple authors rarely, if ever, results >> in an r-. Similarly, multiple bugs is rarely an issue for new contributors. >> >> Ojan >> >> On Thu, Jul 9, 2009 at 1:30 PM, Mark Rowe <mr...@apple.com> wrote: >> >>> >>> On 2009-07-09, at 08:02, Joe Mason wrote: >>> >>> Maciej Stachowiak wrote: >>>> >>>>> Now that my attention has been called to it, it's starting to bug me >>>>> that everyone formats their ChangeLog entries slightly differently. How >>>>> about this as the canonical format (with prepare-ChangeLog encouraging >>>>> it)? >>>>> >>>> >>>> That reminds me: how do we format a patch with multiple authors? I've >>>> been doing this: >>>> >>>> 2009-07-08 Maciej Stachowiak <m...@apple.com> >>>>> Make prepare-ChangeLog less shouty >>>>> https://bugs.webkit.org/show_bug.cgi?id=27098 >>>>> >>>> > Authors: Maciej Stachowiak <m...@apple.com>, Joe Mason < >>>> joe.ma...@torchmobile.com> >>>> >>>>> Reviewed by Mark Rowe. >>>>> * Scripts/prepare-ChangeLog: >>>>> >>>> >>>> So, the main author (or whichever one is submitting the patch if that's >>>> unclear) in the header, then a separate "Authors" line above the Reviewer >>>> line with everyone who deserves credit. >>>> >>> >>> I've never seen this format used in WebKit patches. >>> >>> - Mark >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
