[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn checkpoint: r27139 - checkpoints

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-10-13 21:46:55 CEST

Jay Levitt wrote:
> On 10/13/2007 12:12 PM, Justin Erenkrantz wrote:
>> On Oct 13, 2007 12:55 AM, Karl Fogel <kfogel@red-bean.com> wrote:
>>> How about: "anything you would have formerly attached to an issue as a
>>> patch", for starters? Now we can just say a revision number instead.
>> But, then, it's impossible to review it via email because we don't
>> have diffs.
>> All I'm suggesting is that we turn back on diffs and socially tell
>> folks, "don't be a turd" about giving nit-pick comments to anything in
>> /checkpoints. Yet, if the intent of /checkpoints is that
>> occassionally folks will be asked to look in it, then that implies we
>> need easy ways to review what is there. -- justin
> If I'm understanding, /checkpoints is essentially a centralized,
> versioned working copy. So you really don't want diffs internal to a
> checkpoint.
> If the diffs don't show up again when you merge a checkpoint into trunk,
> then that's the bug that needs fixing.

Exactly. You can't see the diffs when Karl squirrels away patches in his
local disk, either, and that's fine. What matters is the change dropped
into a live branch -- that's the diff to review. If Karl wants early
feedback on his work in progress, then he needs to use a regular feature
branch and work within the established policies for commits to our tree.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Sat Oct 13 21:46:55 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.