Karl Fogel wrote:
> I propose there's a consensus now on just using lightweight branches
> in /branches for multi-stage work -- that is, for the sort of thing
> that we earlier (and perhaps misguidedly) proposed /checkpoints for.
>
> Assuming no one disagrees, we should move /checkpoints/relative-externals/
> to /branches/relative-externals/, and from then on the branch should
> just follow the guidelines in
>
> http://subversion.tigris.org/hacking.html#lightweight-branches
>
> After that, /checkpoints should be removed.
>
> Blair should probably be the one to do this, since it's his working
> copy that would be affected, and there's no point causing him an
> inconvenient surprise.
I'm just going to drop this checkpoint with a real commit, hopefully tonight.
When I get the real commit into trunk, I'll delete /checkpoints.
I do wish we could have a point to drop patches, but as Justin pointed out,
diff'ing of patches is ugly.
There are no really lightweight branches though. You end up doing the same
svnmerge.py thing to bring the branch up to date to test it, which happened to
me on my branch, even though I wasn't really planning on going that far.
Having patch files are nice, because they "automatically" rebase themselves onto
trunk, and are lightweight, since you can just do an "svn update", test your
changes, make changes, "svn diff", and checkpoint the diff.
So I suggest we have a checkpoints place for diffs with no diff emails.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 18 03:01:36 2007