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...@codematters.co.uk> on 2002/06/12 16:07:57 UTC
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
rooneg@tigris.org writes:
> Author: rooneg
> Date: 2002-06-12 04:15 GMT
> New Revision: 2162
>
> Added:
> trunk/subversion/clients/cmdline/rollback-cmd.c
> Modified:
> trunk/subversion/clients/cmdline/cl.h
> trunk/subversion/clients/cmdline/main.c
> trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn--help_stdout
> trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn--version_stdout
> trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout
> trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn_stderr
> Log:
> Add an 'svn rollback' command, which reverts a given revision in your working
> copy using svn_client_merge().
What am I doing wrong?
% svn st -v bar
_ 8 6 pm bar
% svn rollback -r5 bar
C ./bar
Why is that a conflict when the merge seems to work
% svn revert bar
Reverted bar
% svn merge -r6:5 bar bar
G ./bar
or
% svn revert bar
Reverted bar
% svn merge -r8:5 bar bar
G ./bar
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: down with rollback! (was: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
>
> --> Rollback and merge are "two ways to say the same thing"
>
>
> Being of a Python mindset rather than Perl, I see that as Badness(tm)
Well, by that argument, 'svn up' is just a special case of 'svn
switch'. But I guess we don't want to get rid of 'svn up'. :-)
[Although knowing Greg, he'd probably like that. "Just make
everything into fetch!"]
> So... count me as a -0.5 on a 'svn rollback' command. There have been a
> couple use cases for rollback detailed on this thread. Just put those into a
> "simple recipe" cookbook of SVN tasks.
Oooh, a cookbook. I like that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: down with rollback! (was: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 07:13:53PM -0700, Blair Zajac wrote:
> Garrett Rooney wrote:
> > ok, you guys convinced me, i've removed it in revision 2178.
>
> And I assume you used rollback in svn to roll it back :)
actually, i didn't, because i didn't want to get used to having it
around ;-)
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: down with rollback! (was: svn commit: rev 2162 -
trunk/subversion/clients/cmdline
trunk/subversion/tests/clients/cmdline/getopt_tests_data)
Posted by Blair Zajac <bl...@orcaware.com>.
Garrett Rooney wrote:
> ok, you guys convinced me, i've removed it in revision 2178.
And I assume you used rollback in svn to roll it back :)
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: down with rollback! (was: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 03:22:17PM -0700, Greg Stein wrote:
> On Wed, Jun 12, 2002 at 03:37:19PM -0500, Karl Fogel wrote:
> > Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > this is certainly a possibility. what do people think?
> > >
> > > is it worth it to have this command at all? i'm perfectly willing to
> > > just 'svn rm' the file and be done with it if we'd rather just have
> > > people learn to use 'svn merge' to do what they want.
> >
> > I think this confusion is a clue -- let's not have it.
> >
> > I was originally for it, but the confusion between the two possible
> > interpretations of "rollback"'s meaning makes me recant. If people
> > just use merge instead, they'll always know what they're getting.
>
> After reading through this thread... yes, I'm of a similar mind.
>
> --> Rollback and merge are "two ways to say the same thing"
>
>
> Being of a Python mindset rather than Perl, I see that as Badness(tm)
>
> So... count me as a -0.5 on a 'svn rollback' command. There have been a
> couple use cases for rollback detailed on this thread. Just put those into a
> "simple recipe" cookbook of SVN tasks.
>
> "to reverse the changes of rev R in your WC, do ..."
> "to return your working copy to rev R (as local mods), do ..."
ok, you guys convinced me, i've removed it in revision 2178.
someone else can write the cookbook ;-)
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
down with rollback! (was: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 12, 2002 at 03:37:19PM -0500, Karl Fogel wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > this is certainly a possibility. what do people think?
> >
> > is it worth it to have this command at all? i'm perfectly willing to
> > just 'svn rm' the file and be done with it if we'd rather just have
> > people learn to use 'svn merge' to do what they want.
>
> I think this confusion is a clue -- let's not have it.
>
> I was originally for it, but the confusion between the two possible
> interpretations of "rollback"'s meaning makes me recant. If people
> just use merge instead, they'll always know what they're getting.
After reading through this thread... yes, I'm of a similar mind.
--> Rollback and merge are "two ways to say the same thing"
Being of a Python mindset rather than Perl, I see that as Badness(tm)
So... count me as a -0.5 on a 'svn rollback' command. There have been a
couple use cases for rollback detailed on this thread. Just put those into a
"simple recipe" cookbook of SVN tasks.
"to reverse the changes of rev R in your WC, do ..."
"to return your working copy to rev R (as local mods), do ..."
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> this is certainly a possibility. what do people think?
>
> is it worth it to have this command at all? i'm perfectly willing to
> just 'svn rm' the file and be done with it if we'd rather just have
> people learn to use 'svn merge' to do what they want.
I think this confusion is a clue -- let's not have it.
I was originally for it, but the confusion between the two possible
interpretations of "rollback"'s meaning makes me recant. If people
just use merge instead, they'll always know what they're getting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 10:34:38AM -0700, Bill Tutt wrote:
> I think I'm coming to the conclusion that the rollback concept is too
> susceptible to misunderstanding. I'm seriously beginning to think that
> this little shortcut isn't worth providing. Especailly via a GUI. A "svn
> log" dialog can have a button on it that allows the user to update the
> WC to the specified revision.
this is certainly a possibility. what do people think?
is it worth it to have this command at all? i'm perfectly willing to
just 'svn rm' the file and be done with it if we'd rather just have
people learn to use 'svn merge' to do what they want.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Bill Tutt <ra...@lyra.org>.
I think I'm coming to the conclusion that the rollback concept is too
susceptible to misunderstanding. I'm seriously beginning to think that
this little shortcut isn't worth providing. Especailly via a GUI. A "svn
log" dialog can have a button on it that allows the user to update the
WC to the specified revision.
It's so much simpler that way.
Bill
----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 07:17:09PM +0200, Sander Striker wrote:
> > From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> > Sent: 12 June 2002 18:59
> > On Wed, Jun 12, 2002 at 05:53:06PM +0100, Philip Martin wrote:
> >
> >> I see, the problem is one of expectation.
> >>
> >> I expected 'svn rollback -r 5 bar' to undo all the changes between
> >> revisions CURRENT and 5. What it does is to undo the change between
> >> revisions 5 and 4.
> >
> > right now, we just revert the actual revision you give us.
>
> Ah. I must admit that I also expected 'svn rollback -r 5 bar' to
> mean what Philip thought.
i figured that one could easily script that behavior, and that this
would let one easily revert a selected revision, which seems like it
would be nice to have. on the other hand, i can see how it would be
nice to be able to say 'roll back to revision x', but i'm not sure how
to provide both behaviors and have the command be simple and hard to
get wrong.
> And I wonder if it is a good idea to allow 'svn rollback' to
> mean revert all changes between CURRENT and CURRENT - 1.
i'd be ok with that, but how do we deal with mixed revision working
copies? 'svn rollback foo bar' where foo is at revision 5 and bar is
at revision 6... do we roll foo to 4 and bar to 5?
> > i was also considering the possibility of interpreting 'svn rollback
> > -r 10:15' to mean 'revert revisions 10, 11, 12, 13, 14, and 15'. what
> > do people think of that?
>
> I'm not keen on having different meanings for the same option.
yeah, i would like to keep the syntax for this command as simple as
possible, which is why i went with just the single '-r rev'.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 12:15:00PM -0500, cmpilato@collab.net wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > On Wed, Jun 12, 2002 at 05:53:06PM +0100, Philip Martin wrote:
> >
> > > I see, the problem is one of expectation.
> > >
> > > I expected 'svn rollback -r 5 bar' to undo all the changes between
> > > revisions CURRENT and 5. What it does is to undo the change between
> > > revisions 5 and 4.
> >
> > right now, we just revert the actual revision you give us.
>
> While appreciative of the addition of the new subcommand, I dislike
> the current behavior. The notion of a "rollback to a revision X"
> means to restore the state of the file as it was in revision X
> (meaning undoing all changes between X and what is in the working
> copy). To undo a specific revision, one can use `svn diff' and `patch
> -R', or perhaps we could have an `svn undo' subcommand.
i think this may be the best way to go, given the number of people who
assumed the behavior should be that way. if nobody objects, i'll make
this change later today, and possibly have the 'undo' command to do
what 'rollback' is currently doing.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 12:29:27PM -0500, Ben Collins-Sussman wrote:
> cmpilato@collab.net writes:
>
> > The notion of a "rollback to a revision X" means to restore the
> > state of the file as it was in revision X (meaning undoing all
> > changes between X and what is in the working copy).
>
> You mean, 'svn up -rX file'? :-)
won't this update the text base as well, making it rather difficult to
commit the change?
> > To undo a specific revision, one can use `svn diff' and `patch -R',
>
> You mean, 'svn merge -rX:Y file'? :-)
yes, but the whole point of these commands is to provide a shorthand
for commonly used merge commands to make life easier ;-)
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> > ack, that's a good point. i guess 'undo' isn't the appropriate name
> > for what my initial 'rollback' implementation did. in any event, it
> > doesn't change the fact that the vast majority of people all had the
> > same idea about what 'svn rollback' should do, and it just happened
> > that the one person who felt otherwise was the person who coded it :/
>
> Right. `Undo' was just something I shot off quickly in a mail, not a
> well-thought-out suggestion. And as Garrett mentioned, there has so
> far only been one person (Garrett himself) who has mentioned being
> confused about what rollback means. I think the word itself is fairly
> intuitive, and our definition of what it means (or, should mean)
> aligns with what at least one other tool (VSS) considers a "rollback".
I think I misspoke. I now seem to recall that VSS's rollback might
behave a little differently, that maybe it just deleted from version
history the mods between ROLLBACK_REVISION and HEAD. It's been a
couple years since I used the tool, so sorry if my memory was foggy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by cm...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Wed, Jun 12, 2002 at 11:44:27AM -0700, Bill Tutt wrote:
> > > From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> > > i think we can avoid this problem by being more clear in the 'help'
> > > output for each command and sticking with good command names. yes, i
> > > had a different idea of what rollback should do that apparently
> > > everyone else, but if there had been an 'undo' command, i don't think
> > > i would have tried to use 'rollback' to get that functionality.
> > >
> >
> > I'm now not even sure what the difference between undo and revert is. We
> > already have a revert command.
>
> ack, that's a good point. i guess 'undo' isn't the appropriate name
> for what my initial 'rollback' implementation did. in any event, it
> doesn't change the fact that the vast majority of people all had the
> same idea about what 'svn rollback' should do, and it just happened
> that the one person who felt otherwise was the person who coded it :/
Right. `Undo' was just something I shot off quickly in a mail, not a
well-thought-out suggestion. And as Garrett mentioned, there has so
far only been one person (Garrett himself) who has mentioned being
confused about what rollback means. I think the word itself is fairly
intuitive, and our definition of what it means (or, should mean)
aligns with what at least one other tool (VSS) considers a "rollback".
> > To turn the issue upside down for a second looking for other options: Is
> > there any reason we just couldn't make "update -r N" not change the WCs
> > recorded text-base, and entries data? Isn't that what the user probably
> > wanted anyway?
>
> now we're opening a whole new can of worms... opinions? i'm not sure
> what i think about it.
When I do `svn update -r N', I certainly don't want `svn status' showing my
working copy as a bunch of mods! -1 (no veto) all over that mess.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 03:01:02PM -0500, Ben Collins-Sussman wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > "True" moves:
> >
> > - If you want to move in time, just 'svn up -rN'.
> > - If you want to move in time *and* space, use 'svn switch URL -rN'.
> >
> > "Local mod" moves:
> >
> > - Use 'svn merge' for time and space.
> >
>
> Let me elaborate on this paradigm.
>
> In my mind, 'svn rollback' would simply be a 2nd command added to the
> "local mod" category above, for moving through time only.
>
> In our current world, 'svn up' is a simple convenience wrapper around
> 'svn switch'... for those situations when you want to move in time,
> but not space.
>
> Similarly, I think that 'svn rollback' should be a simple convenience
> wrapper around 'svn merge'.... again, when you want to move in time,
> but not space.
>
> Isn't that simple and clear? [/me hopes others agree]
this makes perfect sense to me.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> "True" moves:
>
> - If you want to move in time, just 'svn up -rN'.
> - If you want to move in time *and* space, use 'svn switch URL -rN'.
>
> "Local mod" moves:
>
> - Use 'svn merge' for time and space.
>
Let me elaborate on this paradigm.
In my mind, 'svn rollback' would simply be a 2nd command added to the
"local mod" category above, for moving through time only.
In our current world, 'svn up' is a simple convenience wrapper around
'svn switch'... for those situations when you want to move in time,
but not space.
Similarly, I think that 'svn rollback' should be a simple convenience
wrapper around 'svn merge'.... again, when you want to move in time,
but not space.
Isn't that simple and clear? [/me hopes others agree]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Ben Collins-Sussman <su...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > To turn the issue upside down for a second looking for other options: Is
> > there any reason we just couldn't make "update -r N" not change the WCs
> > recorded text-base, and entries data? Isn't that what the user probably
> > wanted anyway?
>
> now we're opening a whole new can of worms... opinions? i'm not sure
> what i think about it.
Bad idea. The working copy is supposed to be movable in time and
space. We have two ways of doing this -- one is a *true* move, the
other is just a move only in "local mods".
"True" moves:
- If you want to move in time, just 'svn up -rN'.
- If you want to move in time *and* space, use 'svn switch URL -rN'.
"Local mod" moves:
- Use 'svn merge' for time and space.
There are plenty of use cases for both types of moves. Obviously, the
latter category is good for undoing commits, or porting changes
between branches. The first category is used just when you want to
move to HEAD (people run 'svn up' everyday!), or put part of your wc
on a branch.
Also, if anything, if 'svn up' were moved into the "local mod"
category, it would be *very* confusing to CVS users. Also, there
would be a nasty discrepancy:
"Let me see. 'svn up -rN' is a local mod only, but 'svn up' is a
true move to HEAD?"
Ugh.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 11:44:27AM -0700, Bill Tutt wrote:
> > From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> > i think we can avoid this problem by being more clear in the 'help'
> > output for each command and sticking with good command names. yes, i
> > had a different idea of what rollback should do that apparently
> > everyone else, but if there had been an 'undo' command, i don't think
> > i would have tried to use 'rollback' to get that functionality.
> >
>
> I'm now not even sure what the difference between undo and revert is. We
> already have a revert command.
ack, that's a good point. i guess 'undo' isn't the appropriate name
for what my initial 'rollback' implementation did. in any event, it
doesn't change the fact that the vast majority of people all had the
same idea about what 'svn rollback' should do, and it just happened
that the one person who felt otherwise was the person who coded it :/
> To turn the issue upside down for a second looking for other options: Is
> there any reason we just couldn't make "update -r N" not change the WCs
> recorded text-base, and entries data? Isn't that what the user probably
> wanted anyway?
now we're opening a whole new can of worms... opinions? i'm not sure
what i think about it.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Bill Tutt <ra...@lyra.org>.
> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> On Wed, Jun 12, 2002 at 11:26:31AM -0700, Bill Tutt wrote:
>
> > I think the problem is that it's non-obvious what rollback means to
the
> > user, even if writing both versions of what we think the command
should
> > do is very trivial coding effort wise. Adding user shortcuts that
> > confuse the user isn't helping the user out.
>
> i think we can avoid this problem by being more clear in the 'help'
> output for each command and sticking with good command names. yes, i
> had a different idea of what rollback should do that apparently
> everyone else, but if there had been an 'undo' command, i don't think
> i would have tried to use 'rollback' to get that functionality.
>
I'm now not even sure what the difference between undo and revert is. We
already have a revert command.
To turn the issue upside down for a second looking for other options: Is
there any reason we just couldn't make "update -r N" not change the WCs
recorded text-base, and entries data? Isn't that what the user probably
wanted anyway?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 11:26:31AM -0700, Bill Tutt wrote:
> I think the problem is that it's non-obvious what rollback means to the
> user, even if writing both versions of what we think the command should
> do is very trivial coding effort wise. Adding user shortcuts that
> confuse the user isn't helping the user out.
i think we can avoid this problem by being more clear in the 'help'
output for each command and sticking with good command names. yes, i
had a different idea of what rollback should do that apparently
everyone else, but if there had been an 'undo' command, i don't think
i would have tried to use 'rollback' to get that functionality.
plus, lets recall that we have yet to see anyone else who thought this
should work the way i thought it should work. i don't think the
confusion will be too common, especially if both commands exist.
> > i mean come on, we're talking about one file for 'rollback' (which i
> > just rewrote to work like everyone other than me assumed it should,
> > i'll commit it if we decide we want the command), that's about 100
> > lines, much of which is the header.
> >
> > if we also want 'undo', which would do what my original rollback does,
> > that's another 100 lines of client code. it's nothing at all, and
> > makes life easier for the user.
> >
>
> GUIs make life easier for users. Command line programs with large
> numbers of options don't make anybodies life easier. (Users,
> maintainers, support staff, etc...) I mean just check out how many
> subcommands BitKeeper and Perforce have, it's totally insane.
>
> Bill
> P.S. I'm not saying that some sort of rollback subcommand shouldn't be
> committed, but I do think that there shouldn't be a directly accessible
> menu item in a GUI that displays a dialog or something as the interface
> to a possible "svn rollback" command. In all likelihood the GUI would
> have a button on the "svn log" dialog that when pressed did a "svn
> revert; svn merge" based on the selected revision.
i absolutely agree that in a GUI this is not the right interface, but
in the command line, i do know that i keep having trouble remembering
what i have to pass to 'svn merge' to get this functionality, and i
think that's a bad sign.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 08:59:17PM +0100, Philip Martin wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > there is an 'svn_client_revision_working' which means (according to
> > the header file) 'current, plus local mods'. i haven't pounded on
> > this much, but if you pass it to merge it should generate a diff
> > between what you have currently and whatever other revision you give
> > it.
> >
> > /me crosses his finger since he hasn't delved too deeply into the code...
>
> No, it doesn't do what you think. svn_client_revision_working is used
> in the diff code, but the diff code has three separate paths, one for
> diff with no revision, one for diff with one revision and one for diff
> with two revisions. These paths are effectively three separate
> implementations. The merge code is related to the diff code but only
> implements the two revision path.
>
> If your code works at all, I think you will find that it will take the
> current base revision for whatever target path is given, and remove
> the differences between that revision and the given revision from
> everything under the target path. So going back to my mixed working
> copy
>
> % svn st -v wc
> _ 7 7 pm ./wc
> _ 8 6 pm ./wc/zig
> _ 8 6 pm ./wc/zig/bar
> _ 9 9 pm ./wc/zig/foo
>
>
> A command like 'svn rollback -r5 wc' will subtract the revision 5 to 7
> change from everything. It's not clear that this is correct, it won't
> revert the revision 9 change in wc/zig/foo for example. Subtracting
> the revision 5 to HEAD change is not obviously correct either, it may
> do the wrong thing on wc/zig/bar as it will add the subtract the
> revision 8 to HEAD changes but bar is only at revision 8.
i agree, this is not what we want... i'll look into it and see what
it's actually doing.
> To rollback a mixed revision working copy to a given revision is
> hard. The diff code has an entire editor in libsvn_wc/diff.c to do it.
> That's why I was curious when you claimed to have done it in 100
> lines.
well, it looks like i've got some work cut out for me...
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> there is an 'svn_client_revision_working' which means (according to
> the header file) 'current, plus local mods'. i haven't pounded on
> this much, but if you pass it to merge it should generate a diff
> between what you have currently and whatever other revision you give
> it.
>
> /me crosses his finger since he hasn't delved too deeply into the code...
No, it doesn't do what you think. svn_client_revision_working is used
in the diff code, but the diff code has three separate paths, one for
diff with no revision, one for diff with one revision and one for diff
with two revisions. These paths are effectively three separate
implementations. The merge code is related to the diff code but only
implements the two revision path.
If your code works at all, I think you will find that it will take the
current base revision for whatever target path is given, and remove
the differences between that revision and the given revision from
everything under the target path. So going back to my mixed working
copy
% svn st -v wc
_ 7 7 pm ./wc
_ 8 6 pm ./wc/zig
_ 8 6 pm ./wc/zig/bar
_ 9 9 pm ./wc/zig/foo
A command like 'svn rollback -r5 wc' will subtract the revision 5 to 7
change from everything. It's not clear that this is correct, it won't
revert the revision 9 change in wc/zig/foo for example. Subtracting
the revision 5 to HEAD change is not obviously correct either, it may
do the wrong thing on wc/zig/bar as it will add the subtract the
revision 8 to HEAD changes but bar is only at revision 8.
To rollback a mixed revision working copy to a given revision is
hard. The diff code has an entire editor in libsvn_wc/diff.c to do it.
That's why I was curious when you claimed to have done it in 100
lines.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 08:15:48PM +0100, Philip Martin wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > > My guess is that you either remove revision 5 to 7, or revision 5 to
> > > HEAD, from everything in the wc. If that's the case, it's not clear
> > > to me that it is correct.
> >
> > my current 'make it do what i think everyone else wanted' patch has it
> > doing a merge from the current working copy to the target rev and applying
> > it to the current working copy. so it actually rolls EVERYTHING back
> > to the revision you're asking for, including any local mods. i could
>
> Really? As far as I can tell, if the working copy is at a mixed
> revision there is no single merge command that will do this. The
> merge command takes two fixed revision numbers. To rollback a mixed
> revision working copy, one of the revision numbers has to be set on a
> per item basis.
there is an 'svn_client_revision_working' which means (according to
the header file) 'current, plus local mods'. i haven't pounded on
this much, but if you pass it to merge it should generate a diff
between what you have currently and whatever other revision you give
it.
/me crosses his finger since he hasn't delved too deeply into the code...
> > change that to be between head and the target rev, and i think that
> > should preserve local mods (or try to anyway).
>
> This won't work in general if the working copy is a mixed revision.
yeah, that wouldn't surprise me too much, although i wonder how merge
will deal with mixed revisions for 'svn_client_revision_working'...
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > My guess is that you either remove revision 5 to 7, or revision 5 to
> > HEAD, from everything in the wc. If that's the case, it's not clear
> > to me that it is correct.
>
> my current 'make it do what i think everyone else wanted' patch has it
> doing a merge from the current working copy to the target rev and applying
> it to the current working copy. so it actually rolls EVERYTHING back
> to the revision you're asking for, including any local mods. i could
Really? As far as I can tell, if the working copy is at a mixed
revision there is no single merge command that will do this. The
merge command takes two fixed revision numbers. To rollback a mixed
revision working copy, one of the revision numbers has to be set on a
per item basis.
> change that to be between head and the target rev, and i think that
> should preserve local mods (or try to anyway).
This won't work in general if the working copy is a mixed revision.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 07:51:40PM +0100, Philip Martin wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > i mean come on, we're talking about one file for 'rollback' (which i
> > just rewrote to work like everyone other than me assumed it should,
>
> It's not clear that we were "right" and you were "wrong" :-)
this is certainly a possibility ;-)
> > i'll commit it if we decide we want the command), that's about 100
> > lines, much of which is the header.
>
> Is it that simple? What happens if I have a working copy that is at a
> mixed revision?
>
> % svn st -v wc
> _ 7 7 pm ./wc
> _ 8 6 pm ./wc/zig
> _ 8 6 pm ./wc/zig/bar
> _ 9 9 pm ./wc/zig/foo
>
> How should 'svn rollback -r5 wc' behave?
>
> The current (your original) rollback is well defined. It removes the
> revision 4 to 5 change from everything in the wc. The behaviour I
> initially assumed would require removing the revision 5 to 7 change
> from wc, the revision 5 to 6 change from wc/zig and wc/zig/bar, and
> the revision 5 to 9 change from wc/zig/foo. Have you managed this in
> 100 lines?
>
> My guess is that you either remove revision 5 to 7, or revision 5 to
> HEAD, from everything in the wc. If that's the case, it's not clear
> to me that it is correct.
my current 'make it do what i think everyone else wanted' patch has it
doing a merge from the current working copy to the target rev and applying
it to the current working copy. so it actually rolls EVERYTHING back
to the revision you're asking for, including any local mods. i could
change that to be between head and the target rev, and i think that
should preserve local mods (or try to anyway).
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> i mean come on, we're talking about one file for 'rollback' (which i
> just rewrote to work like everyone other than me assumed it should,
It's not clear that we were "right" and you were "wrong" :-)
> i'll commit it if we decide we want the command), that's about 100
> lines, much of which is the header.
Is it that simple? What happens if I have a working copy that is at a
mixed revision?
% svn st -v wc
_ 7 7 pm ./wc
_ 8 6 pm ./wc/zig
_ 8 6 pm ./wc/zig/bar
_ 9 9 pm ./wc/zig/foo
How should 'svn rollback -r5 wc' behave?
The current (your original) rollback is well defined. It removes the
revision 4 to 5 change from everything in the wc. The behaviour I
initially assumed would require removing the revision 5 to 7 change
from wc, the revision 5 to 6 change from wc/zig and wc/zig/bar, and
the revision 5 to 9 change from wc/zig/foo. Have you managed this in
100 lines?
My guess is that you either remove revision 5 to 7, or revision 5 to
HEAD, from everything in the wc. If that's the case, it's not clear
to me that it is correct.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Bill Tutt <ra...@lyra.org>.
> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> On Wed, Jun 12, 2002 at 11:08:37AM -0700, David Mankin wrote:
> > Maybe "svn rollback" can be a command that just prints a useful
tutorial
> > on svn merge. It can show that if you want to rollback TO a certain
> > version, you use _____ and if you want to rollback the change IN a
> > certain version you use ____. Then it meets everybody's
expectaions
> > (except if they expected it to work...).
>
> that's what perforce does with their 'p4 help move' (or rename, i
> forget). it just tells you how to use 'p4 integrate' to fake it.
> that annoys me every time i have to rename a file at work. if there's
> going to be a way to do something that people would want to do, and
> it's at all non-obvious how one would do it, then we should provide
> the command, assuming it's not a lot of code to do it.
>
I think the problem is that it's non-obvious what rollback means to the
user, even if writing both versions of what we think the command should
do is very trivial coding effort wise. Adding user shortcuts that
confuse the user isn't helping the user out.
> i mean come on, we're talking about one file for 'rollback' (which i
> just rewrote to work like everyone other than me assumed it should,
> i'll commit it if we decide we want the command), that's about 100
> lines, much of which is the header.
>
> if we also want 'undo', which would do what my original rollback does,
> that's another 100 lines of client code. it's nothing at all, and
> makes life easier for the user.
>
GUIs make life easier for users. Command line programs with large
numbers of options don't make anybodies life easier. (Users,
maintainers, support staff, etc...) I mean just check out how many
subcommands BitKeeper and Perforce have, it's totally insane.
Bill
P.S. I'm not saying that some sort of rollback subcommand shouldn't be
committed, but I do think that there shouldn't be a directly accessible
menu item in a GUI that displays a dialog or something as the interface
to a possible "svn rollback" command. In all likelihood the GUI would
have a button on the "svn log" dialog that when pressed did a "svn
revert; svn merge" based on the selected revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 11:08:37AM -0700, David Mankin wrote:
> Maybe "svn rollback" can be a command that just prints a useful tutorial
> on svn merge. It can show that if you want to rollback TO a certain
> version, you use _____ and if you want to rollback the change IN a
> certain version you use ____. Then it meets everybody's expectaions
> (except if they expected it to work...).
that's what perforce does with their 'p4 help move' (or rename, i
forget). it just tells you how to use 'p4 integrate' to fake it.
that annoys me every time i have to rename a file at work. if there's
going to be a way to do something that people would want to do, and
it's at all non-obvious how one would do it, then we should provide
the command, assuming it's not a lot of code to do it.
i mean come on, we're talking about one file for 'rollback' (which i
just rewrote to work like everyone other than me assumed it should,
i'll commit it if we decide we want the command), that's about 100
lines, much of which is the header.
if we also want 'undo', which would do what my original rollback does,
that's another 100 lines of client code. it's nothing at all, and
makes life easier for the user.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svn rollback (Was: Re: svn commit: rev 2162 - ...)
Posted by David Mankin <ma...@ants.com>.
Maybe "svn rollback" can be a command that just prints a useful tutorial
on svn merge. It can show that if you want to rollback TO a certain
version, you use _____ and if you want to rollback the change IN a
certain version you use ____. Then it meets everybody's expectaions
(except if they expected it to work...).
-David Mankin
On 12 Jun 2002 cmpilato@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > cmpilato@collab.net writes:
> >
> > > The notion of a "rollback to a revision X" means to restore the
> > > state of the file as it was in revision X (meaning undoing all
> > > changes between X and what is in the working copy).
> >
> > You mean, 'svn up -rX file'? :-)
>
> No good. We want the rollback to be instantaneously committable.
>
> ---------------------------------------------------------------------
> 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 commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> cmpilato@collab.net writes:
>
> > The notion of a "rollback to a revision X" means to restore the
> > state of the file as it was in revision X (meaning undoing all
> > changes between X and what is in the working copy).
>
> You mean, 'svn up -rX file'? :-)
No good. We want the rollback to be instantaneously committable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> The notion of a "rollback to a revision X" means to restore the
> state of the file as it was in revision X (meaning undoing all
> changes between X and what is in the working copy).
You mean, 'svn up -rX file'? :-)
> To undo a specific revision, one can use `svn diff' and `patch -R',
You mean, 'svn merge -rX:Y file'? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by cm...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Wed, Jun 12, 2002 at 05:53:06PM +0100, Philip Martin wrote:
>
> > I see, the problem is one of expectation.
> >
> > I expected 'svn rollback -r 5 bar' to undo all the changes between
> > revisions CURRENT and 5. What it does is to undo the change between
> > revisions 5 and 4.
>
> right now, we just revert the actual revision you give us.
While appreciative of the addition of the new subcommand, I dislike
the current behavior. The notion of a "rollback to a revision X"
means to restore the state of the file as it was in revision X
(meaning undoing all changes between X and what is in the working
copy). To undo a specific revision, one can use `svn diff' and `patch
-R', or perhaps we could have an `svn undo' subcommand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Striker" <st...@apache.org> writes:
> >> I expected 'svn rollback -r 5 bar' to undo all the changes between
> >> revisions CURRENT and 5. What it does is to undo the change between
> >> revisions 5 and 4.
> >
> > right now, we just revert the actual revision you give us.
>
> Ah. I must admit that I also expected 'svn rollback -r 5 bar' to
> mean what Philip thought.
>
> And I wonder if it is a good idea to allow 'svn rollback' to
> mean revert all changes between CURRENT and CURRENT - 1.
'Last Changed Rev' and 'Last Changed Rev' - 1 might be more useful.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Sander Striker <st...@apache.org>.
> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> Sent: 12 June 2002 18:59
> On Wed, Jun 12, 2002 at 05:53:06PM +0100, Philip Martin wrote:
>
>> I see, the problem is one of expectation.
>>
>> I expected 'svn rollback -r 5 bar' to undo all the changes between
>> revisions CURRENT and 5. What it does is to undo the change between
>> revisions 5 and 4.
>
> right now, we just revert the actual revision you give us.
Ah. I must admit that I also expected 'svn rollback -r 5 bar' to
mean what Philip thought.
And I wonder if it is a good idea to allow 'svn rollback' to
mean revert all changes between CURRENT and CURRENT - 1.
> i was also considering the possibility of interpreting 'svn rollback
> -r 10:15' to mean 'revert revisions 10, 11, 12, 13, 14, and 15'. what
> do people think of that?
I'm not keen on having different meanings for the same option.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 05:53:06PM +0100, Philip Martin wrote:
> I see, the problem is one of expectation.
>
> I expected 'svn rollback -r 5 bar' to undo all the changes between
> revisions CURRENT and 5. What it does is to undo the change between
> revisions 5 and 4.
right now, we just revert the actual revision you give us.
i was also considering the possibility of interpreting 'svn rollback
-r 10:15' to mean 'revert revisions 10, 11, 12, 13, 14, and 15'. what
do people think of that?
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Wed, Jun 12, 2002 at 05:25:47PM +0100, Philip Martin wrote:
>
> > The file is unmodified at rev 8. That's the same as rev 6 when it last
> > changed. I want to rollback to rev 5. What's to revert?
>
> i'm not sure what's going on... try uncommenting the debug printf in
> svn_cl__merge (you'll have to update it to make it compile since we
> changed to const char *'s), and put a similar printf in
> svn_cl__rollback and let me know what the difference is.
>
> when i try things here, the printf's give me exactly the same output,
> so i guess i'm just doing something different than you are...
I see, the problem is one of expectation.
I expected 'svn rollback -r 5 bar' to undo all the changes between
revisions CURRENT and 5. What it does is to undo the change between
revisions 5 and 4.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jun 12, 2002 at 05:25:47PM +0100, Philip Martin wrote:
> > The implementation isn't reverting the file in the working copy prior to
> > merging AFAICT. That's prolly the problem.
>
> The file is unmodified at rev 8. That's the same as rev 6 when it last
> changed. I want to rollback to rev 5. What's to revert?
i'm not sure what's going on... try uncommenting the debug printf in
svn_cl__merge (you'll have to update it to make it compile since we
changed to const char *'s), and put a similar printf in
svn_cl__rollback and let me know what the difference is.
when i try things here, the printf's give me exactly the same output,
so i guess i'm just doing something different than you are...
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Philip Martin <ph...@codematters.co.uk>.
"Sander Striker" <st...@apache.org> writes:
> > What am I doing wrong?
> >
> > % svn st -v bar
> > _ 8 6 pm bar
> > % svn rollback -r5 bar
> > C ./bar
> >
> > Why is that a conflict when the merge seems to work
> >
> > % svn revert bar
> > Reverted bar
> > % svn merge -r6:5 bar bar
> > G ./bar
> >
> > or
> >
> > % svn revert bar
> > Reverted bar
> > % svn merge -r8:5 bar bar
> > G ./bar
>
> The implementation isn't reverting the file in the working copy prior to
> merging AFAICT. That's prolly the problem.
The file is unmodified at rev 8. That's the same as rev 6 when it last
changed. I want to rollback to rev 5. What's to revert?
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: rev 2162 - trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline/getopt_tests_data
Posted by Sander Striker <st...@apache.org>.
> From: Philip Martin [mailto:pm@localhost.striker.xs4all.nl]On Behalf Of
> Philip Martin
> Sent: 12 June 2002 18:08
> rooneg@tigris.org writes:
>
> > Author: rooneg
> > Date: 2002-06-12 04:15 GMT
> > New Revision: 2162
> >
> > Added:
> > trunk/subversion/clients/cmdline/rollback-cmd.c
> > Modified:
> > trunk/subversion/clients/cmdline/cl.h
> > trunk/subversion/clients/cmdline/main.c
> > trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn--help_stdout
> > trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn--version_stdout
> > trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout
> > trunk/subversion/tests/clients/cmdline/getopt_tests_data/svn_stderr
> > Log:
> > Add an 'svn rollback' command, which reverts a given revision in your working
> > copy using svn_client_merge().
>
> What am I doing wrong?
>
> % svn st -v bar
> _ 8 6 pm bar
> % svn rollback -r5 bar
> C ./bar
>
> Why is that a conflict when the merge seems to work
>
> % svn revert bar
> Reverted bar
> % svn merge -r6:5 bar bar
> G ./bar
>
> or
>
> % svn revert bar
> Reverted bar
> % svn merge -r8:5 bar bar
> G ./bar
The implementation isn't reverting the file in the working copy prior to
merging AFAICT. That's prolly the problem.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org