On 10/11/07, David Glasser <glasser@davidglasser.net> wrote:
> On 10/11/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > On Oct 11, 2007 7:40 PM, <glasser@tigris.org> wrote:
> > What is the intent of these 'branches' when they get merged? AFAIK,
> > there's going to be nothing in the mailer notification that shows what
> > changed - except 'copied from checkpoints:rxxxx' and I find that a
> > wholly bad idea. So, suddenly, anything in a checkpoint will not
> > produce diffs. That is an extremely bad thing to me.
> The intention would be to treat them just like a patch that was
> maintained in a working copy --- the merge to trunk (or another
> branch) would be just like a fresh commit as far as logs are
> concerned.
I implemented a similar model for our team, starting a few years back.
A little different structure: I made subdirectories under branches:
build, feature, archived, snapshot, and personal.
Checkpoint looks to be more like 'personal' than 'snapshot', though.
Snapshot is for exactly that: I've got a little python script, double click
to store a snapshot of your working copy. Gotta love the low overhead
branching. This policy has saved a few developers from disaster, both
of the "I just hosed my dev server" variety and of the "It was just one
last little tweak to the design, and now I can't figure out what it looked
like when it was working..." sort.
Personal, like snapshot, is excluded from commit emails. This is for
experiments, of the "Hmm... what happens if I... YIKES!!! Hmm... if
I do it again, will it still... YIKES!!!" persuasion. Hey, we're an R&D
shop, it happens, and having an audit trail (in the form of subversion
commits) can be very valuable when trying to figure out, for example,
details of a patent filing.
> The idea is to have a better-versioned replacement for
> "my-feature.patch.37" cluttering up everyone's working directories,
> not to replace the normal review process.
> > BTW, I'm not a fan of making unilateral changes without discussion
> > first. IRC is *never* a place to make binding decisions about how we
> > as a group operate.
> Hey, it's all in version control --- if it's not a good idea, we can
> always rm it later.
I'm not one of the people who counts here, but I can at least give an
endorsement from the perspective of "it works pretty well in the field".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 08:33:30 2007