Hi Mark,
I am both an SVN and CVS user (more CVS than SVN). I tend to
instinctively look under replace with when i want to revert a file
(since with CVS you use replace with latest from head to revert). Most
of the world uses CVS at the moment, so they will be used to the CVS way
of doing things. When/if they move to SVN we want that transition to be
as seemless as possible. Adding a replace with base revision action
would help their transition.
The other replace with operations already perform a revert before
updating, so i don't think the user would be surprised if they lost
stuff (since it is already doing this). If I replaced a directory, I
would expect any uncommited stuff in it to be removed.
As for the dialog. To be consistent with the other replace actions, i
would prefer to not display it. The other replace actions display a
warning when there is stuff with local changes. Perhaps we should not
be reverting, but instead updating to the specified version?
Whetever happens, we should definitely have a revert operation because
as you pointed out, that is the SVN terminiology for it. I was merely
suggesing having a different way of doing it (using the CVS
terminiology). It also looks a bit odd having a compare with base, but
no replace with.
Cheers,
Brock
Mark Phippard wrote:
>Brock Janiczak <brockj@tpg.com.au> wrote on 08/03/2005 05:44:07 AM:
>
>
>
>>I recently had the same thought (but i hadn't gotten around to actually
>>
>>
>doing
>
>
>>it). The replace with base action should use the revert functionality,
>>
>>
>but
>
>
>>not display the revert dialog. If you go into the replace menu you
>>
>>
>should be
>
>
>>prepared for everything to get replaced (unlike the revert action).
>>
>>If no one objects, i will add this function on the weekend.
>>
>>
>
>I would not say that I am against this change, I am just not in favor of
>it in general.
>
>I think our goal should be to make a good Subversion client, not emulate
>every last feature of the CVS client. I think we should use Subversion
>terminology in all areas so that it is clear what Subversion commands are
>being run. In the long run, I think this works in our favor as it makes
>the nice market of Subversion books and other materials relevant to what
>we are doing.
>
>In general I also do not think it is a good UI idea to offer multiple
>paths to the same functionality. In the long run it is just confusing.
>
>Since we have the other Replace with options I suppose it makes sense to
>add this one too. I kind of think that it should to the exact same thing
>as Revert, including the dialog. If we do not do this, then the option is
>going to undo Deletes, Moves and Copies, and I am not sure that would be
>the expected behavior. By presenting the dialog we are at least putting
>all of this in front of the user.
>
>Mark
>
>
>
>
>
>_____________________________________________________________________________
>Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
>_____________________________________________________________________________
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
>
>
>
Received on Thu Aug 4 19:50:40 2005