You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Karl Palsson <kp...@cisco.com> on 2003/08/07 19:49:07 UTC
revert -keep?
Hi,
Coming from a clearcase background, I'm finding the revert behaviour a bit unnerving.
In particular, the behaviour of
http://subversion.tigris.org/project_faq.html#revert
"Making the svn revert command require an explicit target—even if that target is just '.'—is one way
of accomplishing that. This requirement (as well as requiring you to supply the --recursive (-R)
flag if you want that behavior) is intended to make you really think about what you're doing,
because once your files are reverted, your local modifications are gone forever."
In a clearcase uncheckout, you have the option of either removing or keeping your modified files.
if you choose to remove, the behaviour is as per subversion, if you choose to keep, you get
filename.keep and later .keep.2 and .keep.3 and so on.
I'm running
svn, version 0.26.0 (r6550)
compiled Jul 31 2003, 02:46:58
which I feel is pretty up to date, and it doesn't appear to be an option under svn help revert
Is this a planned feature? Is there an issue ID I can track?
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Karl Palsson <kp...@cisco.com>.
>> Karl Palsson <kp...@cisco.com> writes:
>>
>>> In a clearcase uncheckout, you have the option of either removing or
>>> keeping your modified files. if you choose to remove, the behaviour is
>>> as per subversion, if you choose to keep, you get filename.keep and
>>> later .keep.2 and .keep.3 and so on.
>>>
>> You're not required to use 'svn revert' at all; it's a just a
>> convenience for removing local changes. It's not the same as
>> "uncheckout", because you never declared the edit to begin with. And
>> in a similar vein, you can just manually copy your changed files
>> elsewhere before running 'svn revert'.
>>
>
> I'd like to point out that the CVS equivalent command to 'svn revert' is
> 'cvs update -C filename'. This command *does* keep the modified copy
> around under a .#filename.version file. Offering the same thing in svn,
> while technically only a "convenience" for manually copying the files,
> is likely to prevent people being disappointed that their local changes
> were lost.
>
Ben, I see your point of the explicit checkout vs cvs/subversion style and
that's fine, I just personally find it odd that there are a number of mentions
of how subversion does its absolute best to guarantee no user data loss, and
then there's just revert that messes with that. (others opinions may vary of
course :)
With that in mind, would anyone object to a patch that adds a --keep-mods option
to keep all changes?
This would be in relation to
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=221423
and
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=161591
One of them suggests that the default be to --keep-mods, and then the default
could also be recursive,
I'd be quite happy to just have --keep optional, but if anyone has any serious
objections, then I'll keep it as my own change.
Of course, I spose this just got beyond users@
I am proposing that this only effect _files_ changed, not added or deleted, or
directories added or deleted. This is mainly for selfish reasons of not being
entirely sure how I'd want to keep mods of adds/deletes/moves.
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: revert -keep?
Posted by Karl Palsson <kp...@cisco.com>.
>> Karl Palsson <kp...@cisco.com> writes:
>>
>>> In a clearcase uncheckout, you have the option of either removing or
>>> keeping your modified files. if you choose to remove, the behaviour is
>>> as per subversion, if you choose to keep, you get filename.keep and
>>> later .keep.2 and .keep.3 and so on.
>>>
>> You're not required to use 'svn revert' at all; it's a just a
>> convenience for removing local changes. It's not the same as
>> "uncheckout", because you never declared the edit to begin with. And
>> in a similar vein, you can just manually copy your changed files
>> elsewhere before running 'svn revert'.
>>
>
> I'd like to point out that the CVS equivalent command to 'svn revert' is
> 'cvs update -C filename'. This command *does* keep the modified copy
> around under a .#filename.version file. Offering the same thing in svn,
> while technically only a "convenience" for manually copying the files,
> is likely to prevent people being disappointed that their local changes
> were lost.
>
Ben, I see your point of the explicit checkout vs cvs/subversion style and
that's fine, I just personally find it odd that there are a number of mentions
of how subversion does its absolute best to guarantee no user data loss, and
then there's just revert that messes with that. (others opinions may vary of
course :)
With that in mind, would anyone object to a patch that adds a --keep-mods option
to keep all changes?
This would be in relation to
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=221423
and
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=161591
One of them suggests that the default be to --keep-mods, and then the default
could also be recursive,
I'd be quite happy to just have --keep optional, but if anyone has any serious
objections, then I'll keep it as my own change.
Of course, I spose this just got beyond users@
I am proposing that this only effect _files_ changed, not added or deleted, or
directories added or deleted. This is mainly for selfish reasons of not being
entirely sure how I'd want to keep mods of adds/deletes/moves.
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by kf...@collab.net.
Karl Palsson <kp...@cisco.com> writes:
> alllll gone. The 'Protection' afforded by requiring a parameter to
> revert is effectively useless in my mind. You very quickly get to the
> point where the . is automatic, just like ./blah to execute stuff.
It's not useless, because you can't habituate to a command you don't
run often. Therefore, this protects you if you accidentally typed
"revert" when you meant to type "someothercommand" -- in those cases
where "someothercommand" is one of those commands usually used with an
implicit '.' target.
This is subtly different from the kind of habituation you're talking
about.
(Of course, if you _always_ give an explicit target to every svn
command you run, then this would give no protection. But most people
don't use svn like that.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Sat 2003-08-09 at 14:44:52 -0700, you wrote
> Ben Collins-Sussman wrote:
[...]
> >This use-case happens to us all the time in svn development. We're
> >working on a large change, and whoops, need to switch gears, so we put
> >the whole changeset aside:
> >
> > $ svn diff > mypatch
> > $ svn revert . -R
> > $ svn up
> > $ edit files, commit, etc.
> > $ patch -p0 < mypatch
> > ...then continue on where you left off.
> >
> >Your proposal seems much clunkier to me. You'd rather have 'svn
> >revert' leave a bunch of 'backup' files around your working
> >copy... and then later hand-move them back into place? :-/
> >
>
> Yeah, I would, disk space is cheap. I wasn't proposing making it the
> default however. If you don't approve, that's fine with me, but all you
> have to do right now is leave out the diff > mypatch, and it's alllll gone.
Then don't (mis-)use svn revert at all, but simply reverse-apply the patch:
$ svn diff > mypatch
$ patch -pX -R <mypatch
$ svn up
$ edit files, commit, etc.
$ patch -p0 < mypatch
...then continue on where you left off.
(without looking I am not sure if -p0, -p1 or whatever is necessary.)
It may happen occasionlly that you made such big changes that you
still need to revert (if you did major restructuring of your tree),
but at least you have the major work on the save side.
> The 'Protection' afforded by requiring a parameter to revert is effectively
> useless in my mind.
Well, IMHO, using "svn revert" is similar to using "rm" with a pattern
or "-rf", i.e. be very careful about it and think twice before you
actually hit return.
Using revert for preparing a WC for an update kind of looks like using
"cp -a" and "rm -rf" instead of mv. Yes, sometimes you have to go this
way (e.g. moves across partitions), but then you should be double
careful about what you do.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Palsson <kp...@cisco.com> writes:
> But rm has -i.
>
> That's all I'm proposing.
Prompting the user seems pretty harmless to me, why not go for it. My
response was aimed at the idea that 'svn revert' should automatically
make backups of local mods, which I don't like.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Karl Palsson <kp...@cisco.com>.
>
> I don't follow your train of thought.
>
> The maxim "don't lose any user data" is indeed one we live by, but we
> apply the maxim to situations where the data might be lost *without*
> the user expecting it to happen. For example:
>
> * when receiving a conflicting update, create all three fulltexts
>
> * don't allow the deletion of something that's out-of-date
>
> * don't ever overwrite an unversioned file
>
> But is this situation, you're objecting to the safety of a command
> who's *purpose* in life is to toss changes! It's like objecting to
> the unix 'rm' command -- "but doctor, it might delete data!" -- "then
> don't do that."
But rm has -i.
That's all I'm proposing.
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Palsson <kp...@cisco.com> writes:
> Yeah, I would, disk space is cheap. I wasn't proposing making it the
> default however. If you don't approve, that's fine with me, but all
> you have to do right now is leave out the diff > mypatch, and it's
> alllll gone. The 'Protection' afforded by requiring a parameter to
> revert is effectively useless in my mind. You very quickly get to the
> point where the . is automatic, just like ./blah to execute stuff.
I don't follow your train of thought.
The maxim "don't lose any user data" is indeed one we live by, but we
apply the maxim to situations where the data might be lost *without*
the user expecting it to happen. For example:
* when receiving a conflicting update, create all three fulltexts
* don't allow the deletion of something that's out-of-date
* don't ever overwrite an unversioned file
But is this situation, you're objecting to the safety of a command
who's *purpose* in life is to toss changes! It's like objecting to
the unix 'rm' command -- "but doctor, it might delete data!" -- "then
don't do that."
The svn commandline client is like any unix program -- flexible enough
to let you do cool things, but then also a tiny bit dangerous if used
carelsessly. An educated svn user should understand that 'svn
revert', just like unix 'rm', should be handled with care. If this is
too unfriendly, then that's why we have GUIs. (I imagine a GUI,
could, for example, back up the edited files into a 'trashcan' before
running svn_client_revert(). Changesets could then be resurrected
from the trash.)
But my point is: 'svn revert' exists to destroy local changes, not to
back them up. If users want to back them up (with 'svn diff') before
destroying them, they're certainly free to do so. And I think the
book could certainly address this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Karl Palsson <kp...@cisco.com>.
Ben Collins-Sussman wrote:
> David Mankin <da...@ants.com> writes:
>
>
>>A common use case in my work place (still using CVS for now) is this:
>>developer is making some experimental changes, gets an urgent call to
>>fix another problem, updates to HEAD, gets tons of conflicts in the
>>modified file, runs 'cvs update -C' to get back to a clean copy of the
>>file, fixes the urgent problem, goes back to sort out what happened in
>>the conflicted merge. Sure the developer could copy the modified file
>>off before running 'cvs update -C' or 'svn revert', but what if he
>>forgets? With CVS he is safe (and even already trained not to make
>>the copy); with svn his changes are lost forever.
>
>
> This use-case happens to us all the time in svn development. We're
> working on a large change, and whoops, need to switch gears, so we put
> the whole changeset aside:
>
> $ svn diff > mypatch
> $ svn revert . -R
> $ svn up
> $ edit files, commit, etc.
> $ patch -p0 < mypatch
> ...then continue on where you left off.
>
> Your proposal seems much clunkier to me. You'd rather have 'svn
> revert' leave a bunch of 'backup' files around your working
> copy... and then later hand-move them back into place? :-/
>
Yeah, I would, disk space is cheap. I wasn't proposing making it the default
however. If you don't approve, that's fine with me, but all you have to do
right now is leave out the diff > mypatch, and it's alllll gone. The
'Protection' afforded by requiring a parameter to revert is effectively useless
in my mind. You very quickly get to the point where the . is automatic, just
like ./blah to execute stuff.
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Ben Collins-Sussman <su...@collab.net>.
David Mankin <da...@ants.com> writes:
> A common use case in my work place (still using CVS for now) is this:
> developer is making some experimental changes, gets an urgent call to
> fix another problem, updates to HEAD, gets tons of conflicts in the
> modified file, runs 'cvs update -C' to get back to a clean copy of the
> file, fixes the urgent problem, goes back to sort out what happened in
> the conflicted merge. Sure the developer could copy the modified file
> off before running 'cvs update -C' or 'svn revert', but what if he
> forgets? With CVS he is safe (and even already trained not to make
> the copy); with svn his changes are lost forever.
This use-case happens to us all the time in svn development. We're
working on a large change, and whoops, need to switch gears, so we put
the whole changeset aside:
$ svn diff > mypatch
$ svn revert . -R
$ svn up
$ edit files, commit, etc.
$ patch -p0 < mypatch
...then continue on where you left off.
Your proposal seems much clunkier to me. You'd rather have 'svn
revert' leave a bunch of 'backup' files around your working
copy... and then later hand-move them back into place? :-/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Sat, Aug 09, 2003 at 11:30:12PM +0200, Michael Wood wrote:
> On Sat, Aug 09, 2003 at 12:59:32PM -0700, David Mankin wrote:
> >
> >
> > --On Saturday, August 09, 2003 10:43 AM -0500 Ben Collins-Sussman
> > <su...@collab.net> wrote:
> >
> > >Karl Palsson <kp...@cisco.com> writes:
> > >
> > >>In a clearcase uncheckout, you have the option of either removing or
> > >>keeping your modified files. if you choose to remove, the behaviour is
> > >>as per subversion, if you choose to keep, you get filename.keep and
> > >>later .keep.2 and .keep.3 and so on.
> > >>
> > ...
> > >
> > >You're not required to use 'svn revert' at all; it's a just a
> > >convenience for removing local changes. It's not the same as
> > >"uncheckout", because you never declared the edit to begin with. And
> > >in a similar vein, you can just manually copy your changed files
> > >elsewhere before running 'svn revert'.
> > >
> >
> > I'd like to point out that the CVS equivalent command to 'svn revert' is
> > 'cvs update -C filename'. This command *does* keep the modified copy
> > around under a .#filename.version file. Offering the same thing in svn,
> > while technically only a "convenience" for manually copying the files, is
> > likely to prevent people being disappointed that their local changes were
> > lost.
>
> Subversion will only throw away the local changes iff you use --force.
> Is that not reminder enough?
Sorry. Must have been asleep when I wrote that. It's false.
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by David Mankin <da...@ants.com>.
--On Saturday, August 09, 2003 11:30 PM +0200 Michael Wood
<mw...@its.uct.ac.za> wrote:
>> I'd like to point out that the CVS equivalent command to 'svn revert' is
>> 'cvs update -C filename'. This command *does* keep the modified copy
>> around under a .#filename.version file. Offering the same thing in svn,
>> while technically only a "convenience" for manually copying the files,
>> is likely to prevent people being disappointed that their local changes
>> were lost.
>
> Subversion will only throw away the local changes iff you use --force.
> Is that not reminder enough?
Not so! 'svn revert' (at least in svn 0.26.0) will destroy your changes
when you don't use --force.
Karl Palsson wrote:
> Ben Collins-Sussman wrote:
>> This use-case happens to us all the time in svn development. We're
>> working on a large change, and whoops, need to switch gears, so we put
>> the whole changeset aside:
>>
>> $ svn diff > mypatch
>> $ svn revert . -R
>> $ svn up
>> $ edit files, commit, etc.
>> $ patch -p0 < mypatch
>> ...then continue on where you left off.
>>
>> Your proposal seems much clunkier to me. You'd rather have 'svn
>> revert' leave a bunch of 'backup' files around your working
>> copy... and then later hand-move them back into place? :-/
>>
>
> Yeah, I would, disk space is cheap. I wasn't proposing making it the
> default however. If you don't approve, that's fine with me, but all you
> have to do right now is leave out the diff > mypatch, and it's alllll
> gone. The 'Protection' afforded by requiring a parameter to revert is
> effectively useless in my mind. You very quickly get to the point where
> the . is automatic, just like ./blah to execute stuff.
Like Karl, I think it would be better if it would keep your changes in a .#
file. Then we could have --force mean "don't keep my changes, I really
want them gone." Then it would behave as Michael assumed it would.
(Also, Ben, your solution only works when changes can be correctly detected
and restored with diff/patch.)
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Sat, Aug 09, 2003 at 12:59:32PM -0700, David Mankin wrote:
>
>
> --On Saturday, August 09, 2003 10:43 AM -0500 Ben Collins-Sussman
> <su...@collab.net> wrote:
>
> >Karl Palsson <kp...@cisco.com> writes:
> >
> >>In a clearcase uncheckout, you have the option of either removing or
> >>keeping your modified files. if you choose to remove, the behaviour is
> >>as per subversion, if you choose to keep, you get filename.keep and
> >>later .keep.2 and .keep.3 and so on.
> >>
> ...
> >
> >You're not required to use 'svn revert' at all; it's a just a
> >convenience for removing local changes. It's not the same as
> >"uncheckout", because you never declared the edit to begin with. And
> >in a similar vein, you can just manually copy your changed files
> >elsewhere before running 'svn revert'.
> >
>
> I'd like to point out that the CVS equivalent command to 'svn revert' is
> 'cvs update -C filename'. This command *does* keep the modified copy
> around under a .#filename.version file. Offering the same thing in svn,
> while technically only a "convenience" for manually copying the files, is
> likely to prevent people being disappointed that their local changes were
> lost.
Subversion will only throw away the local changes iff you use --force.
Is that not reminder enough?
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by David Mankin <da...@ants.com>.
--On Saturday, August 09, 2003 10:43 AM -0500 Ben Collins-Sussman
<su...@collab.net> wrote:
> Karl Palsson <kp...@cisco.com> writes:
>
>> In a clearcase uncheckout, you have the option of either removing or
>> keeping your modified files. if you choose to remove, the behaviour is
>> as per subversion, if you choose to keep, you get filename.keep and
>> later .keep.2 and .keep.3 and so on.
>>
...
>
> You're not required to use 'svn revert' at all; it's a just a
> convenience for removing local changes. It's not the same as
> "uncheckout", because you never declared the edit to begin with. And
> in a similar vein, you can just manually copy your changed files
> elsewhere before running 'svn revert'.
>
I'd like to point out that the CVS equivalent command to 'svn revert' is
'cvs update -C filename'. This command *does* keep the modified copy
around under a .#filename.version file. Offering the same thing in svn,
while technically only a "convenience" for manually copying the files, is
likely to prevent people being disappointed that their local changes were
lost.
A common use case in my work place (still using CVS for now) is this:
developer is making some experimental changes, gets an urgent call to fix
another problem, updates to HEAD, gets tons of conflicts in the modified
file, runs 'cvs update -C' to get back to a clean copy of the file, fixes
the urgent problem, goes back to sort out what happened in the conflicted
merge. Sure the developer could copy the modified file off before running
'cvs update -C' or 'svn revert', but what if he forgets? With CVS he is
safe (and even already trained not to make the copy); with svn his changes
are lost forever.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: revert -keep?
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Palsson <kp...@cisco.com> writes:
> In a clearcase uncheckout, you have the option of either removing or
> keeping your modified files. if you choose to remove, the behaviour is
> as per subversion, if you choose to keep, you get filename.keep and
> later .keep.2 and .keep.3 and so on.
>
> Is this a planned feature? Is there an issue ID I can track?
I don't think this idea makes much sense.
In clearcase, you declare which files you're about to edit
("checkout"), or undo that declaration ("uncheckout"). So it makes
sense that in such a universe, the user gets a choice about whether or
not to preserve the local mods.
In CVS and Subversion, there are no declarations of "intent to edit".
You just edit. The fact that a file has local mods *is* the
declaration of the intent to change. So either the mods are present,
or they're not.
You're not required to use 'svn revert' at all; it's a just a
convenience for removing local changes. It's not the same as
"uncheckout", because you never declared the edit to begin with. And
in a similar vein, you can just manually copy your changed files
elsewhere before running 'svn revert'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org