You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2013/03/12 18:13:34 UTC
svn_client_move7 and mixed-revisions
svn_client_move7 is new in 1.8, it has two new boolean parameters
compared to svn_client_move6: allow_mixed_revisions and metadata_only.
The metadata_only flag is fine but allow_mixed_revisions is a bit odd:
* If @a allow_mixed_revisions is @c FALSE, #SVN_ERR_WC_MIXED_REVISIONS
* will be raised if the move source is a mixed-revision subtree.
* If @a allow_mixed_revisions is TRUE, a mixed-revision move source is
* allowed. This parameter should be set to FALSE except where backwards
* compatibility to svn_client_move6() is required.
In 1.7 a call to svn_client_move6 produces copy+delete with no move
tracking.
In 1.8 a call to svn_client_move7 with allow_mixed_revisions=FALSE, the
recommended setting, produces copy+delete with move tracking or an
error. But if allow_mixed_revisions=TRUE things are more complicated.
The result is copy+delete with move tracking some of the time and
copy+delete without move tracking at other times.
The legacy API svn_client_move6 sets allow_mixed_revisions=TRUE to
enable the behaviour.
I think this concept of legacy behaviour is odd. Are there reasons to
prefer want the old untracked copy+delete? I can't see why an
application would want that. I see that the new behaviour will result
in errors where the old behaviour would do a copy+delete but I think the
error is better.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn_client_move7 and mixed-revisions
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Mar 12, 2013 at 8:44 PM, Branko Čibej <br...@wandisco.com> wrote:
...
> I have to agree with Mark. As long as we don't know how to track a
> mixed-revision move in all cases, then it's better to revert to copy+delete
> than to block the move. Ideally only for those parts of the move source that
> are actually out of date with regard to the repository, but I take it we
> haven't got that far yet.
Random thought: can move tracking be "repaired" after the fact? If
there were an API to do so, users / GUI's could repair such "broken
(legacy) moves" at some point (either automatically or at the request
of the user after he's gotten some hint by the GUI (and perhaps after
some operations such as updating, if necessary)).
--
Johan
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I exposed metadata_only but hard-coded allow_mixed_revisions=FALSE.
I've exposed allow_mixed_revisions in org.subversion.apache and changed
the legacy org.tigris.apache to pass allow_mixed_revisions=true. See
r1456006.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: woensdag 13 maart 2013 10:42
>> To: Branko Čibej
>> Cc: Mark Phippard; C. Michael Pilato; Philip Martin;
>> dev@subversion.apache.org
>> Subject: Re: svn_client_move7 and mixed-revisions
>>
>> Branko Čibej <br...@wandisco.com> writes:
>>
>> > I have to agree with Mark. As long as we don't know how to track a
>> > mixed-revision move in all cases, then it's better to revert to
>> > copy+delete than to block the move. Ideally only for those parts of the
>> > move source that are actually out of date with regard to the repository,
>> > but I take it we haven't got that far yet.
>>
>> Do we expose this feature in the JavaHL bindings?
>
> As long as we didn't switch JavaHL to svn_client_move7() we exposed the option as default via svn_client_move() upto svn_client_move6().
>
> But I think Brane switched JavaHL to enable the metadata only move. I would have to check the commit to see which value he enabled.
I exposed metadata_only but hard-coded allow_mixed_revisions=FALSE.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: svn_client_move7 and mixed-revisions
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: woensdag 13 maart 2013 10:42
> To: Branko Čibej
> Cc: Mark Phippard; C. Michael Pilato; Philip Martin;
> dev@subversion.apache.org
> Subject: Re: svn_client_move7 and mixed-revisions
>
> Branko Čibej <br...@wandisco.com> writes:
>
> > I have to agree with Mark. As long as we don't know how to track a
> > mixed-revision move in all cases, then it's better to revert to
> > copy+delete than to block the move. Ideally only for those parts of the
> > move source that are actually out of date with regard to the repository,
> > but I take it we haven't got that far yet.
>
> Do we expose this feature in the JavaHL bindings?
As long as we didn't switch JavaHL to svn_client_move7() we exposed the option as default via svn_client_move() upto svn_client_move6().
But I think Brane switched JavaHL to enable the metadata only move. I would have to check the commit to see which value he enabled.
Bert
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> I have to agree with Mark. As long as we don't know how to track a
> mixed-revision move in all cases, then it's better to revert to
> copy+delete than to block the move. Ideally only for those parts of the
> move source that are actually out of date with regard to the repository,
> but I take it we haven't got that far yet.
Do we expose this feature in the JavaHL bindings?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn_client_move7 and mixed-revisions
Posted by Branko Čibej <br...@wandisco.com>.
On 12.03.2013 20:37, Mark Phippard wrote:
> On Tue, Mar 12, 2013 at 3:23 PM, Philip Martin
> <philip.martin@wandisco.com <ma...@wandisco.com>> wrote:
>
> Mark Phippard <markphip@gmail.com <ma...@gmail.com>> writes:
>
> > On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato
> <cmpilato@collab.net <ma...@collab.net>>wrote:
> >
> >> On 03/12/2013 02:14 PM, Philip Martin wrote:
> >> > Philip Martin <philip.martin@wandisco.com
> <ma...@wandisco.com>> writes:
> >> >
> >> >> Yes, I believe removing allow_mixed_revisions is the solution.
> >> >
> >> > Eek! It's propagated further than I realised:
> >> >
> >> > $ svn move --help
> >> > ...
> >> > --allow-mixed-revisions : Allow operation on
> mixed-revision working
> >> copy.
> >> > Use of this option is not
> recommended!
> >> > Please run 'svn update' instead.
> >> >
> >> > Is the legacy copy+delete without move tracking something
> users really
> >> > want?
> >>
> >> Can they still get the legacy behavior by issuing explicit 'svn
> copy' and
> >> 'svn delete' commands? If so, might that not be enough of a
> workaround for
> >> those that want this behavior?
>
> Yes.
>
> > If you want to do that to command line users, it is up to you.
> >
> > As an API consumer, I would be pissed if this is a requirement.
> IDE users
> > in particular rarely have working copies that are not mixed
> revision as the
> > GUI's tend to steer you in that direction. It is obviously easy
> to just
> > update the root of your working copy in a GUI, but when you have a
> > graphical tool showing you changed files from the repository, a
> lot of
> > people use those options too. And those pretty much have to
> only update
> > the items you select. Some GUI users seem to live in that mode of
> > operating.
>
> I don't understand this. You seem to be asking for move tracking
> to be
> unreliable in order to avoid a message that tells users how to
> make move
> work.
>
>
> I do not think users care about move tracking in this context.
> Suppose you are in a GUI tool and you are dragging and dropping a
> file from one folder to another. More than anything, I think they
> just expect this action to succeed. In my case, inside Eclipse, we do
> not get a chance to even get involved in this operation until very
> late in the process. I *think* we can still block the move, but the
> user experience is not that good. And what are we supposed to tell
> the user?
>
> As Bert has mentioned, another common place for this is refactoring.
> A user is using the tools for their language and doing some action
> that causes files or folders to be renamed as part of that process.
> Having the version control constantly complaining and blocking them
> just gives us a bad name.
>
> Does the user ideally want the best of all worlds here? Of course. I
> am sure if asked they would want all the proper move tracking in place.
>
>
> When the user moves things around some of the 'moves' will show
> up as moves and others will not. How is that sensible? How is
> the user
> supposed to understand what is happening?
>
>
> I assume that you already handle errors from the move API. Why is
> this
> new error not acceptable?
>
>
> What error message do you think we can provide that a user is going to
> understand? Have you ever known users to understand mixed-revision
> working copies? It does not help that SVN does absolutely nothing to
> help the user out. A single user working alone does a commit and
> their working copy is mixed revision. If you are the user, why would
> you expect that you need to run update after a commit when you know
> you are the one and only user working on the repository?
>
> On the other side of this, is the Enterprise users that will be forced
> to run update when they want to move or rename something, and update
> is going to possibly pull in changes they are not ready to review or
> receive.
I have to agree with Mark. As long as we don't know how to track a
mixed-revision move in all cases, then it's better to revert to
copy+delete than to block the move. Ideally only for those parts of the
move source that are actually out of date with regard to the repository,
but I take it we haven't got that far yet.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn_client_move7 and mixed-revisions
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Mar 12, 2013 at 3:23 PM, Philip Martin
<ph...@wandisco.com>wrote:
> Mark Phippard <ma...@gmail.com> writes:
>
> > On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato <cmpilato@collab.net
> >wrote:
> >
> >> On 03/12/2013 02:14 PM, Philip Martin wrote:
> >> > Philip Martin <ph...@wandisco.com> writes:
> >> >
> >> >> Yes, I believe removing allow_mixed_revisions is the solution.
> >> >
> >> > Eek! It's propagated further than I realised:
> >> >
> >> > $ svn move --help
> >> > ...
> >> > --allow-mixed-revisions : Allow operation on mixed-revision working
> >> copy.
> >> > Use of this option is not recommended!
> >> > Please run 'svn update' instead.
> >> >
> >> > Is the legacy copy+delete without move tracking something users really
> >> > want?
> >>
> >> Can they still get the legacy behavior by issuing explicit 'svn copy'
> and
> >> 'svn delete' commands? If so, might that not be enough of a workaround
> for
> >> those that want this behavior?
>
> Yes.
>
> > If you want to do that to command line users, it is up to you.
> >
> > As an API consumer, I would be pissed if this is a requirement. IDE
> users
> > in particular rarely have working copies that are not mixed revision as
> the
> > GUI's tend to steer you in that direction. It is obviously easy to just
> > update the root of your working copy in a GUI, but when you have a
> > graphical tool showing you changed files from the repository, a lot of
> > people use those options too. And those pretty much have to only update
> > the items you select. Some GUI users seem to live in that mode of
> > operating.
>
> I don't understand this. You seem to be asking for move tracking to be
> unreliable in order to avoid a message that tells users how to make move
> work.
I do not think users care about move tracking in this context. Suppose you
are in a GUI tool and you are dragging and dropping a file from one folder
to another. More than anything, I think they just expect this action to
succeed. In my case, inside Eclipse, we do not get a chance to even get
involved in this operation until very late in the process. I *think* we
can still block the move, but the user experience is not that good. And
what are we supposed to tell the user?
As Bert has mentioned, another common place for this is refactoring. A
user is using the tools for their language and doing some action that
causes files or folders to be renamed as part of that process. Having the
version control constantly complaining and blocking them just gives us a
bad name.
Does the user ideally want the best of all worlds here? Of course. I am
sure if asked they would want all the proper move tracking in place.
> When the user moves things around some of the 'moves' will show
> up as moves and others will not. How is that sensible? How is the user
> supposed to understand what is happening?
> I assume that you already handle errors from the move API. Why is this
> new error not acceptable?
>
What error message do you think we can provide that a user is going to
understand? Have you ever known users to understand mixed-revision working
copies? It does not help that SVN does absolutely nothing to help the user
out. A single user working alone does a commit and their working copy is
mixed revision. If you are the user, why would you expect that you need to
run update after a commit when you know you are the one and only user
working on the repository?
On the other side of this, is the Enterprise users that will be forced to
run update when they want to move or rename something, and update is going
to possibly pull in changes they are not ready to review or receive.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: svn_client_move7 and mixed-revisions
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 12 maart 2013 20:32
> To: Mark Phippard
> Cc: C. Michael Pilato; Philip Martin; Branko Čibej;
> dev@subversion.apache.org
> Subject: Re: svn_client_move7 and mixed-revisions
>
> Philip Martin <ph...@wandisco.com> writes:
>
> > I don't understand this. You seem to be asking for move tracking to be
> > unreliable in order to avoid a message that tells users how to make move
> > work. When the user moves things around some of the 'moves' will show
> > up as moves and others will not. How is that sensible? How is the user
> > supposed to understand what is happening?
>
> Further, one of the ways users get mixed-revision working copies is by
> committing. If one then moves such a mixed revision and it degrades to
> copy+delete it is not generally possible to commit the 'move' because
> some part of the delete will be out-of-date. If we don't make users
> update before move they often have to run update before comitting. If
> the users have to run update anyway it's far better to get them to do it
> before the move so that move tracking works.
The problem here is that we now require the update before moving. If we can
postpone that requirement to the commit time, there is no problem for
clients like Subclipse and AnkhSVN. A move or copy is an operation that is
performed as part of larger operations, while commits and updates are not.
Those operations are specific to version control.
Moves and copies are often contained in automated tasks like refactoring
tools.
And those refactor tools might change many files, move files, change more
file, move a few more files. And you can't just fail in that last step.
Requiring the user to then perform an update before committing is no
problem. But breaking powerful refactoring tools is.
Bert
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> I don't understand this. You seem to be asking for move tracking to be
> unreliable in order to avoid a message that tells users how to make move
> work. When the user moves things around some of the 'moves' will show
> up as moves and others will not. How is that sensible? How is the user
> supposed to understand what is happening?
Further, one of the ways users get mixed-revision working copies is by
committing. If one then moves such a mixed revision and it degrades to
copy+delete it is not generally possible to commit the 'move' because
some part of the delete will be out-of-date. If we don't make users
update before move they often have to run update before comitting. If
the users have to run update anyway it's far better to get them to do it
before the move so that move tracking works.
--
Philip
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato <cm...@collab.net>wrote:
>
>> On 03/12/2013 02:14 PM, Philip Martin wrote:
>> > Philip Martin <ph...@wandisco.com> writes:
>> >
>> >> Yes, I believe removing allow_mixed_revisions is the solution.
>> >
>> > Eek! It's propagated further than I realised:
>> >
>> > $ svn move --help
>> > ...
>> > --allow-mixed-revisions : Allow operation on mixed-revision working
>> copy.
>> > Use of this option is not recommended!
>> > Please run 'svn update' instead.
>> >
>> > Is the legacy copy+delete without move tracking something users really
>> > want?
>>
>> Can they still get the legacy behavior by issuing explicit 'svn copy' and
>> 'svn delete' commands? If so, might that not be enough of a workaround for
>> those that want this behavior?
Yes.
> If you want to do that to command line users, it is up to you.
>
> As an API consumer, I would be pissed if this is a requirement. IDE users
> in particular rarely have working copies that are not mixed revision as the
> GUI's tend to steer you in that direction. It is obviously easy to just
> update the root of your working copy in a GUI, but when you have a
> graphical tool showing you changed files from the repository, a lot of
> people use those options too. And those pretty much have to only update
> the items you select. Some GUI users seem to live in that mode of
> operating.
I don't understand this. You seem to be asking for move tracking to be
unreliable in order to avoid a message that tells users how to make move
work. When the user moves things around some of the 'moves' will show
up as moves and others will not. How is that sensible? How is the user
supposed to understand what is happening?
I assume that you already handle errors from the move API. Why is this
new error not acceptable?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn_client_move7 and mixed-revisions
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato <cm...@collab.net>wrote:
> On 03/12/2013 02:14 PM, Philip Martin wrote:
> > Philip Martin <ph...@wandisco.com> writes:
> >
> >> Yes, I believe removing allow_mixed_revisions is the solution.
> >
> > Eek! It's propagated further than I realised:
> >
> > $ svn move --help
> > ...
> > --allow-mixed-revisions : Allow operation on mixed-revision working
> copy.
> > Use of this option is not recommended!
> > Please run 'svn update' instead.
> >
> > Is the legacy copy+delete without move tracking something users really
> > want?
>
> Can they still get the legacy behavior by issuing explicit 'svn copy' and
> 'svn delete' commands? If so, might that not be enough of a workaround for
> those that want this behavior?
If you want to do that to command line users, it is up to you.
As an API consumer, I would be pissed if this is a requirement. IDE users
in particular rarely have working copies that are not mixed revision as the
GUI's tend to steer you in that direction. It is obviously easy to just
update the root of your working copy in a GUI, but when you have a
graphical tool showing you changed files from the repository, a lot of
people use those options too. And those pretty much have to only update
the items you select. Some GUI users seem to live in that mode of
operating.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn_client_move7 and mixed-revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 03/12/2013 02:14 PM, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Yes, I believe removing allow_mixed_revisions is the solution.
>
> Eek! It's propagated further than I realised:
>
> $ svn move --help
> ...
> --allow-mixed-revisions : Allow operation on mixed-revision working copy.
> Use of this option is not recommended!
> Please run 'svn update' instead.
>
> Is the legacy copy+delete without move tracking something users really
> want?
Can they still get the legacy behavior by issuing explicit 'svn copy' and
'svn delete' commands? If so, might that not be enough of a workaround for
those that want this behavior?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Yes, I believe removing allow_mixed_revisions is the solution.
Eek! It's propagated further than I realised:
$ svn move --help
...
--allow-mixed-revisions : Allow operation on mixed-revision working copy.
Use of this option is not recommended!
Please run 'svn update' instead.
Is the legacy copy+delete without move tracking something users really
want?
--
Philip
Re: svn_client_move7 and mixed-revisions
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 12.03.2013 18:13, Philip Martin wrote:
>> I think this concept of legacy behaviour is odd. Are there reasons to
>> prefer want the old untracked copy+delete? I can't see why an
>> application would want that. I see that the new behaviour will result
>> in errors where the old behaviour would do a copy+delete but I think the
>> error is better.
>
> I sort of agree with your analysis. Am I right in assuming that the best
> solution would be to simply remove the allow_mixed_revisions parameter?
> This would make the behaviour of svn_client_move6 change, but that's OK,
> IMO, since we do want to always track moves.
Yes, I believe removing allow_mixed_revisions is the solution. Any user
of the svn_client_move6 API has to handle errors, and in 1.8 it simply
gives an error in more cases.
I've been experimenting with a 1.7 client linked to the 1.8 libraries
(build the 1.8 libraries with --disable-full-version-match to get this
to work). The client calls the legacy svn_client_move6 and gets full
1.8 move tracking: conflicts, updates, etc. when the source is
single-rev. But for mixed-rev the libraries silently convert the move
to copy+delete without move tracking.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn_client_move7 and mixed-revisions
Posted by Branko Čibej <br...@wandisco.com>.
On 12.03.2013 18:13, Philip Martin wrote:
> svn_client_move7 is new in 1.8, it has two new boolean parameters
> compared to svn_client_move6: allow_mixed_revisions and metadata_only.
> The metadata_only flag is fine but allow_mixed_revisions is a bit odd:
>
> * If @a allow_mixed_revisions is @c FALSE, #SVN_ERR_WC_MIXED_REVISIONS
> * will be raised if the move source is a mixed-revision subtree.
> * If @a allow_mixed_revisions is TRUE, a mixed-revision move source is
> * allowed. This parameter should be set to FALSE except where backwards
> * compatibility to svn_client_move6() is required.
>
> In 1.7 a call to svn_client_move6 produces copy+delete with no move
> tracking.
>
> In 1.8 a call to svn_client_move7 with allow_mixed_revisions=FALSE, the
> recommended setting, produces copy+delete with move tracking or an
> error. But if allow_mixed_revisions=TRUE things are more complicated.
> The result is copy+delete with move tracking some of the time and
> copy+delete without move tracking at other times.
>
> The legacy API svn_client_move6 sets allow_mixed_revisions=TRUE to
> enable the behaviour.
>
> I think this concept of legacy behaviour is odd. Are there reasons to
> prefer want the old untracked copy+delete? I can't see why an
> application would want that. I see that the new behaviour will result
> in errors where the old behaviour would do a copy+delete but I think the
> error is better.
I sort of agree with your analysis. Am I right in assuming that the best
solution would be to simply remove the allow_mixed_revisions parameter?
This would make the behaviour of svn_client_move6 change, but that's OK,
IMO, since we do want to always track moves.
Alternatively, the reversion to the old behaviour should be hidden by
the implementation, not exposed in the public API.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com