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

Re: svn checkpoint: r27213 - checkpoints/relative-externals

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-10-16 16:17:06 CEST

Blair Zajac wrote:
> Ben Collins-Sussman wrote:
>> On 10/16/07, blair@tigris.org <blair@tigris.org> wrote:
>>> Author: blair
>>> Date: Tue Oct 16 06:58:40 2007
>>> New Revision: 27213
>>> Log:
>>> Initialized merge tracking via "svnmerge" with revisions "1-27141" from
>>> http://svn.collab.net/repos/svn/trunk
>> So now you're using svnmerge.py to carefully keep your 'checkpoint' in
>> sync with trunk. At this point, how is it any different from a
>> feature branch? Is it just the fact that you don't want to write
>> structured log messages or have people review the code?
>> I guess I can understand using /checkpoints as a general anarchy
>> dumping-ground to make backups of patches, but this sort of blurs the
>> line. Why not just make a feature branch and ask folks not to review
>> it yet?
> I know, it's turning out that way, not really what I wanted :)
> My original intention to using it was to dump the patch somewhere while
> I worked out one issue and wrote a real log message, which is my
> intention to finish this morning.

There is something to be said about throwing the current output from 'svn diff'
on a remote server somewhere as Karl has been doing with pastebin.ca. No need
to keep the branch up to date. Also, unlike pastebin, which I understand
deletes pastes after a year, we'll alway have record of our patches.

Maybe we should have /anarchy or /checkpoints also be a place to dump patch files.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 16 16:21:05 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.