On Wed, 25 Oct 2006, Madan S. wrote:
> On Tue, 24 Oct 2006 01:46:36 +0530, Daniel Rall <email@example.com> wrote:
> >On Thu, 19 Oct 2006, Malcolm Rowe wrote:
> >>On Wed, Oct 18, 2006 at 05:23:08PM -0700, firstname.lastname@example.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.
Received on Wed Oct 25 00:17:14 2006
- application/pgp-signature attachment: stored