You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2007/10/16 14:05:28 UTC
Re: svn checkpoint: r27213 - checkpoints/relative-externals
On 10/16/07, blair@tigris.org <bl...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/16/07, Karl Fogel <kf...@red-bean.com> wrote:
> I think it's fine to move from /checkpoints into /branches, when
> something turns out to need a typical feature branch.
Or, just enable diffs on /checkpoints. =P -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by "C. Michael Pilato" <cm...@collab.net>.
Erik Huelsmann wrote:
> Do we have a policy / social issue with 1 commit branches? If not, why
> not just start a branch if you don't know? (not knowing implies
> /probably/ more than 1 commit...)
No social issue I know of. In fact, we use 1- (or few-) commit branches for
some backports of bug fixes to maintenance branches, don't we?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/16/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Ben Collins-Sussman" <su...@red-bean.com> writes:
> > 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?
>
> Well, you doesn't always know when you start something how long it's
> going to take, or how many commits, etc.
Do we have a policy / social issue with 1 commit branches? If not, why
not just start a branch if you don't know? (not knowing implies
/probably/ more than 1 commit...)
> I think it's fine to move from /checkpoints into /branches, when
> something turns out to need a typical feature branch.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> 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?
Well, you doesn't always know when you start something how long it's
going to take, or how many commits, etc.
I think it's fine to move from /checkpoints into /branches, when
something turns out to need a typical feature branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Karl Fogel <kf...@red-bean.com>.
Blair Zajac <bl...@orcaware.com> writes:
>> pastebin.ca defaults to 'forever', FYI
>
> OK. I thought I saw a note in an issue that the patch would disappear
> in a year. So you changed the default setting?
Not that I know of, it's just always been 'forever' when I go there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Blair Zajac <bl...@orcaware.com>.
Karl Fogel wrote:
> Blair Zajac <bl...@orcaware.com> writes:
>> 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.
>
> pastebin.ca defaults to 'forever', FYI
OK. I thought I saw a note in an issue that the patch would disappear in a
year. So you changed the default setting?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Karl Fogel <kf...@red-bean.com>.
Blair Zajac <bl...@orcaware.com> writes:
> 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.
pastebin.ca defaults to 'forever', FYI
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
> Ben Collins-Sussman wrote:
>> On 10/16/07, blair@tigris.org <bl...@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.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn checkpoint: r27213 - checkpoints/relative-externals
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
> On 10/16/07, blair@tigris.org <bl...@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.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org