You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chris Rose <ch...@messagingdirect.com> on 2008/04/01 14:28:48 UTC
Re: SVN 1.5 - beta1 - svn checkout
In our nightly builds it's convenient to use checkout as an update as
well; we can choose to blow away our source code and our nightly code
update scripts Just Work(tm) despite the absence of a checked out copy.
It's not a fundamentally critical feature, to be sure, but it's nice in
this case.
David Glasser wrote:
> On Mon, Mar 31, 2008 at 2:21 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
>> "David Glasser" <gl...@davidglasser.net> writes:
>>
>> > That doesn't mean that the UI has to reflect this implementation. I
>> > don't see why --accept is useful for checkout; I think it should be
>> > removed.
>>
>> The UI already does. Unless you change 'svn checkout URL existing-wc'
>> to error out instead of updating it.
>
> Sure, I think the fact that this works is a bug. checkout and update
> are conceptually different operations, no matter how our current
> wc/client code works. A more structured working copy would treat them
> rather differently. I don't see why we should go out of our way to
> encourage people to use checkout as update, even if it happens to work
> (and I'd be OK with making it be an error).
>
> Is there any useful reason to use "svn checkout URL existing-wc"?
>
> --dave
>
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
crose@planetci.com
Re: SVN 1.5 - beta1 - svn checkout
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, May 23, 2008 at 11:25 AM, C. Michael Pilato <cm...@collab.net> wrote:
> David Glasser wrote:
>>
>> On Wed, Apr 2, 2008 at 5:04 PM, Karl Fogel <kf...@red-bean.com> wrote:
>>>
>>> "David Glasser" <gl...@davidglasser.net> writes:
>>>>
>>>> I'm a little torn; some of my wc-ng ideas include making checkout a
>>>> little specialler.
>>>>
>>>> But even if you're using checkout to restart a checkout, would you
>>>> ever want to use --accept?
>>>
>>> Good point. I'm fine with disallowing --accept for checkout. (And
>>> always better to disallow now and then allow later if we have a reason
>>> to, than vice versa.)
>>
>> For the record, we didn't do this. Is this a problem?
>
> Isn't this, like, a one-line trivial change? Just make it happen. There is
> no meaningful interpretation of 'svn checkout --accept'.
OK, r31396, nominated for backport to 1.5.x.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Wed, Apr 2, 2008 at 5:04 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> "David Glasser" <gl...@davidglasser.net> writes:
>>> I'm a little torn; some of my wc-ng ideas include making checkout a
>>> little specialler.
>>>
>>> But even if you're using checkout to restart a checkout, would you
>>> ever want to use --accept?
>> Good point. I'm fine with disallowing --accept for checkout. (And
>> always better to disallow now and then allow later if we have a reason
>> to, than vice versa.)
>
> For the record, we didn't do this. Is this a problem?
Isn't this, like, a one-line trivial change? Just make it happen. There is
no meaningful interpretation of 'svn checkout --accept'.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVN 1.5 - beta1 - svn checkout
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Apr 2, 2008 at 5:04 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
>> I'm a little torn; some of my wc-ng ideas include making checkout a
>> little specialler.
>>
>> But even if you're using checkout to restart a checkout, would you
>> ever want to use --accept?
>
> Good point. I'm fine with disallowing --accept for checkout. (And
> always better to disallow now and then allow later if we have a reason
> to, than vice versa.)
For the record, we didn't do this. Is this a problem?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> I'm a little torn; some of my wc-ng ideas include making checkout a
> little specialler.
>
> But even if you're using checkout to restart a checkout, would you
> ever want to use --accept?
Good point. I'm fine with disallowing --accept for checkout. (And
always better to disallow now and then allow later if we have a reason
to, than vice versa.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Apr 2, 2008 at 4:07 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Ben Collins-Sussman" <su...@red-bean.com> writes:
> > History:
> >
> > * Checkout and update used to be different codepaths. Neither was
> > restartable. Right before launching 1.0, we decided this was a
> > showstopper.
> >
> > * kfogel and I made checkout/update into a single codepath which was
> > inherently restartable. A checkout just creates a working copy with
> > "all items missing", and requests an update.
> >
> > * A side-effect of this change, it turned out that checkouts were
> > restartable by *either* 'co' or 'up'... they both ended up invoking
> > the same codepath. We decided it was nifty cool to be so flexible,
> > and left the side-effect alone.
>
> Well, then my memory is playing tricks on me -- I thought the usage
> decision was older than that. But I believe you.
>
> In any case, do we like the property of "restartable by re-invoking the
> same command" ?
I'm a little torn; some of my wc-ng ideas include making checkout a
little specialler.
But even if you're using checkout to restart a checkout, would you
ever want to use --accept?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> History:
>
> * Checkout and update used to be different codepaths. Neither was
> restartable. Right before launching 1.0, we decided this was a
> showstopper.
>
> * kfogel and I made checkout/update into a single codepath which was
> inherently restartable. A checkout just creates a working copy with
> "all items missing", and requests an update.
>
> * A side-effect of this change, it turned out that checkouts were
> restartable by *either* 'co' or 'up'... they both ended up invoking
> the same codepath. We decided it was nifty cool to be so flexible,
> and left the side-effect alone.
Well, then my memory is playing tricks on me -- I thought the usage
decision was older than that. But I believe you.
In any case, do we like the property of "restartable by re-invoking the
same command" ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by Ben Collins-Sussman <su...@red-bean.com>.
History:
* Checkout and update used to be different codepaths. Neither was
restartable. Right before launching 1.0, we decided this was a
showstopper.
* kfogel and I made checkout/update into a single codepath which was
inherently restartable. A checkout just creates a working copy with
"all items missing", and requests an update.
* A side-effect of this change, it turned out that checkouts were
restartable by *either* 'co' or 'up'... they both ended up invoking
the same codepath. We decided it was nifty cool to be so flexible,
and left the side-effect alone.
On Tue, Apr 1, 2008 at 2:00 PM, David Glasser <gl...@davidglasser.net> wrote:
> I see; Issue #730. Of course, checkout/update were implemented
> differently back then I think; now you can just restart checkouts with
> an update.
>
> --dave
>
>
>
> On Tue, Apr 1, 2008 at 10:28 AM, C. Michael Pilato <cm...@collab.net> wrote:
> > This was not an oversight, it was a deliberate design decision. I believe
> > the enhancement issue's summary was something to the effect of "checkouts
> > should be restartable".
> >
> >
> >
> > Chris Rose wrote:
> > > In our nightly builds it's convenient to use checkout as an update as
> > > well; we can choose to blow away our source code and our nightly code
> > > update scripts Just Work(tm) despite the absence of a checked out copy.
> > >
> > > It's not a fundamentally critical feature, to be sure, but it's nice in
> > > this case.
> > >
> > > David Glasser wrote:
> > >> On Mon, Mar 31, 2008 at 2:21 PM, Eric Gillespie <ep...@pretzelnet.org>
> > >> wrote:
> > >>> "David Glasser" <gl...@davidglasser.net> writes:
> > >>>
> > >>> > That doesn't mean that the UI has to reflect this implementation. I
> > >>> > don't see why --accept is useful for checkout; I think it should be
> > >>> > removed.
> > >>>
> > >>> The UI already does. Unless you change 'svn checkout URL existing-wc'
> > >>> to error out instead of updating it.
> > >>
> > >> Sure, I think the fact that this works is a bug. checkout and update
> > >> are conceptually different operations, no matter how our current
> > >> wc/client code works. A more structured working copy would treat them
> > >> rather differently. I don't see why we should go out of our way to
> > >> encourage people to use checkout as update, even if it happens to work
> > >> (and I'd be OK with making it be an error).
> > >>
> > >> Is there any useful reason to use "svn checkout URL existing-wc"?
> > >>
> > >> --dave
> > >>
> > >
> >
> >
> > --
> > C. Michael Pilato <cm...@collab.net>
> > CollabNet <> www.collab.net <> Distributed Development On Demand
> >
> >
>
>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by David Glasser <gl...@davidglasser.net>.
I see; Issue #730. Of course, checkout/update were implemented
differently back then I think; now you can just restart checkouts with
an update.
--dave
On Tue, Apr 1, 2008 at 10:28 AM, C. Michael Pilato <cm...@collab.net> wrote:
> This was not an oversight, it was a deliberate design decision. I believe
> the enhancement issue's summary was something to the effect of "checkouts
> should be restartable".
>
>
>
> Chris Rose wrote:
> > In our nightly builds it's convenient to use checkout as an update as
> > well; we can choose to blow away our source code and our nightly code
> > update scripts Just Work(tm) despite the absence of a checked out copy.
> >
> > It's not a fundamentally critical feature, to be sure, but it's nice in
> > this case.
> >
> > David Glasser wrote:
> >> On Mon, Mar 31, 2008 at 2:21 PM, Eric Gillespie <ep...@pretzelnet.org>
> >> wrote:
> >>> "David Glasser" <gl...@davidglasser.net> writes:
> >>>
> >>> > That doesn't mean that the UI has to reflect this implementation. I
> >>> > don't see why --accept is useful for checkout; I think it should be
> >>> > removed.
> >>>
> >>> The UI already does. Unless you change 'svn checkout URL existing-wc'
> >>> to error out instead of updating it.
> >>
> >> Sure, I think the fact that this works is a bug. checkout and update
> >> are conceptually different operations, no matter how our current
> >> wc/client code works. A more structured working copy would treat them
> >> rather differently. I don't see why we should go out of our way to
> >> encourage people to use checkout as update, even if it happens to work
> >> (and I'd be OK with making it be an error).
> >>
> >> Is there any useful reason to use "svn checkout URL existing-wc"?
> >>
> >> --dave
> >>
> >
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 - beta1 - svn checkout
Posted by "C. Michael Pilato" <cm...@collab.net>.
This was not an oversight, it was a deliberate design decision. I believe
the enhancement issue's summary was something to the effect of "checkouts
should be restartable".
Chris Rose wrote:
> In our nightly builds it's convenient to use checkout as an update as
> well; we can choose to blow away our source code and our nightly code
> update scripts Just Work(tm) despite the absence of a checked out copy.
>
> It's not a fundamentally critical feature, to be sure, but it's nice in
> this case.
>
> David Glasser wrote:
>> On Mon, Mar 31, 2008 at 2:21 PM, Eric Gillespie <ep...@pretzelnet.org>
>> wrote:
>>> "David Glasser" <gl...@davidglasser.net> writes:
>>>
>>> > That doesn't mean that the UI has to reflect this implementation. I
>>> > don't see why --accept is useful for checkout; I think it should be
>>> > removed.
>>>
>>> The UI already does. Unless you change 'svn checkout URL existing-wc'
>>> to error out instead of updating it.
>>
>> Sure, I think the fact that this works is a bug. checkout and update
>> are conceptually different operations, no matter how our current
>> wc/client code works. A more structured working copy would treat them
>> rather differently. I don't see why we should go out of our way to
>> encourage people to use checkout as update, even if it happens to work
>> (and I'd be OK with making it be an error).
>>
>> Is there any useful reason to use "svn checkout URL existing-wc"?
>>
>> --dave
>>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand