You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Malcolm Rowe <ma...@farside.org.uk> on 2006/10/19 15:45:55 UTC
Re: svn commit: r22030 - branches/merge-tracking
On Wed, Oct 18, 2006 at 05:23:08PM -0700, dlr@tigris.org wrote:
> + operations should change the merge info. Instead, this form of
> + 'copy' will not replicate non-local merge info unless the -u
> + switch (new) is used (a la 'status -u').
>
Bikeshed, but _please_ don't use the --show-updates/-u switch for this - it
really doesn't have anything to do with 'copy'.
Regards,
Malcolm
Re: Flag to preserve offline operation of WC -> WC copy
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 23 Oct 2006, Daniel Rall wrote:
> On Thu, 19 Oct 2006, Malcolm Rowe wrote:
...
> > Bikeshed, but _please_ don't use the --show-updates/-u switch for
> > this - it really doesn't have anything to do with 'copy'.
>
> We're trying to handle a couple use cases here:
>
> 1) Allow WC -> WC 'copy'/'move' commands to continue to support
> offline operation.
>
> 2) Allow WC -> WC 'copy'/'move' commands to propogate both explicity
> merge info (the pre-existing value of the "svn:mergeinfo" property on
> the source path), and implicit merge info (all revisions represented
> by the object at the source path).
>
> An option for 'copy'/'move' will be introduced to support #2. "-u"
> was suggested because it make 'status' contact the repository, which
> is similar to what it'll do here. However, the long name
> "--show-updates" isn't correctly descriptive of what we're doing
> (retrieving any inherited merge info and looking up the revision when
> the source path first appeared). Anyone have a better suggestion?
I've written this up here:
http://subversion.tigris.org/merge-tracking/func-spec.html#copy-move
Re: Flag to preserve offline operation of WC -> WC copy
Posted by David Glasser <gl...@mit.edu>.
On 10/24/06, Madan U Sreenivasan <ma...@collab.net> wrote:
> How about making repos access the default option. That is, by default an
> offline wc to wc copy, would fail saying that access to the respository is
> required, but this could be overridden by using the '--offline' flag, in
> which case, the mergeinfo would be inconsistent until the commit happens.
If I understand you correctly, you're suggesting that every "svn cp
foo bar" would require repository access? If nothing else, that would
not be backwards-compatible, and in any case the ability to do that
operation offline is pretty useful.
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Flag to preserve offline operation of WC -> WC copy
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 25 Oct 2006, Madan S. wrote:
> On Tue, 24 Oct 2006 01:46:36 +0530, Daniel Rall <dl...@collab.net> wrote:
>
> >On Thu, 19 Oct 2006, Malcolm Rowe wrote:
> >
> >>On Wed, Oct 18, 2006 at 05:23:08PM -0700, dlr@tigris.org wrote:
> >>> + operations should change the merge info. Instead, this form of
> >>> + 'copy' will not replicate non-local merge info unless the -u
> >>> + switch (new) is used (a la 'status -u').
> >>
> >>Bikeshed, but _please_ don't use the --show-updates/-u switch for
> >>this - it really doesn't have anything to do with 'copy'.
> >
> >We're trying to handle a couple use cases here:
> >
> >1) Allow WC -> WC 'copy'/'move' commands to continue to support
> >offline operation.
> >
> >2) Allow WC -> WC 'copy'/'move' commands to propogate both explicity
> >merge info (the pre-existing value of the "svn:mergeinfo" property on
> >the source path), and implicit merge info (all revisions represented
> >by the object at the source path).
> >
> >An option for 'copy'/'move' will be introduced to support #2. "-u"
> >was suggested because it make 'status' contact the repository, which
> >is similar to what it'll do here. However, the long name
> >"--show-updates" isn't correctly descriptive of what we're doing
> >(retrieving any inherited merge info and looking up the revision when
> >the source path first appeared). Anyone have a better suggestion?
>
> How about making repos access the default option. That is, by default an
> offline wc to wc copy, would fail saying that access to the respository is
> required, but this could be overridden by using the '--offline' flag, in
> which case, the mergeinfo would be inconsistent until the commit happens.
Changing 'copy' so that RA is the default mode for WC -> WC operation
changes the current behavior of the command. Requiring a flag
maintains the current behavior while still allowing it to play nice
with Merge Tracking.
> Did we discuss this options earlier and reject it for some reason
> during the summit? I dont remember... so bringing it up for
> discussion. Feel free to shoot it down... ;)
We touched on it briefly on Wednesday's discussion.
Re: Flag to preserve offline operation of WC -> WC copy
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Tue, 24 Oct 2006 01:46:36 +0530, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 19 Oct 2006, Malcolm Rowe wrote:
>
>> On Wed, Oct 18, 2006 at 05:23:08PM -0700, dlr@tigris.org wrote:
>> > + operations should change the merge info. Instead, this form of
>> > + 'copy' will not replicate non-local merge info unless the -u
>> > + switch (new) is used (a la 'status -u').
>>
>> Bikeshed, but _please_ don't use the --show-updates/-u switch for
>> this - it really doesn't have anything to do with 'copy'.
>
> We're trying to handle a couple use cases here:
>
> 1) Allow WC -> WC 'copy'/'move' commands to continue to support
> offline operation.
>
> 2) Allow WC -> WC 'copy'/'move' commands to propogate both explicity
> merge info (the pre-existing value of the "svn:mergeinfo" property on
> the source path), and implicit merge info (all revisions represented
> by the object at the source path).
>
> An option for 'copy'/'move' will be introduced to support #2. "-u"
> was suggested because it make 'status' contact the repository, which
> is similar to what it'll do here. However, the long name
> "--show-updates" isn't correctly descriptive of what we're doing
> (retrieving any inherited merge info and looking up the revision when
> the source path first appeared). Anyone have a better suggestion?
How about making repos access the default option. That is, by default an
offline wc to wc copy, would fail saying that access to the respository is
required, but this could be overridden by using the '--offline' flag, in
which case, the mergeinfo would be inconsistent until the commit happens.
Did we discuss this options earlier and reject it for some reason during
the summit? I dont remember... so bringing it up for discussion. Feel free
to shoot it down... ;)
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Flag to preserve offline operation of WC -> WC copy
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 19 Oct 2006, Malcolm Rowe wrote:
> On Wed, Oct 18, 2006 at 05:23:08PM -0700, dlr@tigris.org wrote:
> > + operations should change the merge info. Instead, this form of
> > + 'copy' will not replicate non-local merge info unless the -u
> > + switch (new) is used (a la 'status -u').
>
> Bikeshed, but _please_ don't use the --show-updates/-u switch for
> this - it really doesn't have anything to do with 'copy'.
We're trying to handle a couple use cases here:
1) Allow WC -> WC 'copy'/'move' commands to continue to support
offline operation.
2) Allow WC -> WC 'copy'/'move' commands to propogate both explicity
merge info (the pre-existing value of the "svn:mergeinfo" property on
the source path), and implicit merge info (all revisions represented
by the object at the source path).
An option for 'copy'/'move' will be introduced to support #2. "-u"
was suggested because it make 'status' contact the repository, which
is similar to what it'll do here. However, the long name
"--show-updates" isn't correctly descriptive of what we're doing
(retrieving any inherited merge info and looking up the revision when
the source path first appeared). Anyone have a better suggestion?
- Dan