--dry-run

["Perry E. Metzger" <pe...@piermont.com>]

One of my users, who's an old CVS hand, notes that the fact that 
svn --dry-run doesn't provide them with information when they're doing
commits or updates bothers them. I have told them to use 
svn status --verbose for now, but would it be difficult to get fairly
similar information printed out when update or commit were run with
--dry-run? That's apparently pretty much what cvs -n used to do for them...

-- 
Perry E. Metzger		perry@piermont.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: --dry-run

[Michael W Thelen <th...@cs.utah.edu>]

* Perry E. Metzger <pe...@piermont.com> [2004-04-13 13:27]:
> Anyway, this is a "fit and finish" issue more than anything. I
> realize the information is present with another command. The users are
> just used to doing stuff like "cvs -n update", and having 
> "svn --dry-run update" do the same thing (i.e. print out what 
> svn status -u prints) would reduce retraining.

Being a CVS user and fairly new to SVN myself, I would say it took me maybe a
few hours to get used to 'svn status' and 'svn status -u'.  If these commands
do exactly what your users are looking for, why can't your users also make a
habit of using them?  There is a little brain strain at first, but once you
get used to it 'svn status' and 'svn status -u' work just fine (and are more
intuitive than their CVS counterparts, I'd say).

-- Mike

-- 
Michael W. Thelen
No amount of genius can overcome a preoccupation with detail.
                -- Levy's Eighth Law

Re: --dry-run

[Glenn Maynard <g_...@zewt.org>]

On Tue, Apr 13, 2004 at 02:40:12PM -0500, Ben Collins-Sussman wrote:
> I guess it *could*, but you're the first person in 4 years to ever
> notice or care (or at least mention it).  Maybe you could persuade the
> dev@ list that this is a pressing UI issue...?

I did, but didn't mention it, having had bigger issues at the time.

> There's a limit here, too.  SVN is supposed to be *similar* to CVS, but
> not an exact clone.  The model is the same, the subcommands are mostly
> the same, but we deliberately changed things that we thought were broken
> (like separating 'status' and 'update' functionality, for example, or
> removing the distinction between global and per-subcommand switches).

Yeah; having "cvs -n upd" and "cvs upd -n" not be equivalent was painful UI
brain damage.

For me, it's more an issue of reforming habits--mental retraining, not skills
retraining.  I type "cvs upd -n" all the time, so I tended to try to type
"svn upd -n", too.  I hit a similar problem with commits: I was used to typing
"cvs com", and svn doesn't accept that; I had to switch to "cvs/svn ci".

(Most of this went away after a week or so of use.  Since I use svn side by
side with cvs, it'll never go away completely, but that's little different
than the occasional "ls" typed into a DOS box ...)

-- 
Glenn Maynard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: --dry-run

[Ben Collins-Sussman <su...@collab.net>]

On Tue, 2004-04-13 at 14:29, Perry E. Metzger wrote:

> Right. Could svn --dry-run commit print the same output?

> Exactly. could svn --dry-run update print out the exact same thing
> here, too?

I guess it *could*, but you're the first person in 4 years to ever
notice or care (or at least mention it).  Maybe you could persuade the
dev@ list that this is a pressing UI issue...?

>  The users are
> just used to doing stuff like "cvs -n update", and having 
> "svn --dry-run update" do the same thing (i.e. print out what 
> svn status -u prints) would reduce retraining.

There's a limit here, too.  SVN is supposed to be *similar* to CVS, but
not an exact clone.  The model is the same, the subcommands are mostly
the same, but we deliberately changed things that we thought were broken
(like separating 'status' and 'update' functionality, for example, or
removing the distinction between global and per-subcommand switches).

So I guess what I'm trying to say is:  "feature X should be more like
CVS" isn't *necessarily* a compelling argument in and of itself.  If you
think that a bunch of cranky CVS users are going to be able to learn SVN
with zero retraining, you're being unrealistic.  :-)




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: --dry-run

["Perry E. Metzger" <pe...@piermont.com>]

Ben Collins-Sussman <su...@collab.net> writes:
> On Tue, 2004-04-13 at 14:11, Perry E. Metzger wrote:
>> One of my users, who's an old CVS hand, notes that the fact that 
>> svn --dry-run doesn't provide them with information when they're doing
>> commits or updates bothers them. I have told them to use 
>> svn status --verbose for now, but would it be difficult to get fairly
>> similar information printed out when update or commit were run with
>> --dry-run? That's apparently pretty much what cvs -n used to do for them...
>
> I'm not sure what you're asking here, probably because I'm not much of a
> cvs user, and don't know cvs switches.
>
> If you want to see what 'svn commit' *would* commit, without actually
> committing, just run 'svn status'.  You get instant list of
> modified/scheduled things.

Right. Could svn --dry-run commit print the same output?

> If youw want to see what 'svn up' *would* modify, without actually
> updating, run 'svn status -u'.  It's the same as 'svn status', except
> that it contacts the server and adds little asterisk marks next to every
> file which is out-of-date.

Exactly. could svn --dry-run update print out the exact same thing
here, too?

> (FWIW, the --dry-run flag only exists for 'svn merge'.)

Yes, but the documentation is a bit confusing to users on this.

Anyway, this is a "fit and finish" issue more than anything. I
realize the information is present with another command. The users are
just used to doing stuff like "cvs -n update", and having 
"svn --dry-run update" do the same thing (i.e. print out what 
svn status -u prints) would reduce retraining.

-- 
Perry E. Metzger		perry@piermont.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: --dry-run

[Ben Collins-Sussman <su...@collab.net>]

On Tue, 2004-04-13 at 14:11, Perry E. Metzger wrote:
> One of my users, who's an old CVS hand, notes that the fact that 
> svn --dry-run doesn't provide them with information when they're doing
> commits or updates bothers them. I have told them to use 
> svn status --verbose for now, but would it be difficult to get fairly
> similar information printed out when update or commit were run with
> --dry-run? That's apparently pretty much what cvs -n used to do for them...

I'm not sure what you're asking here, probably because I'm not much of a
cvs user, and don't know cvs switches.

If you want to see what 'svn commit' *would* commit, without actually
committing, just run 'svn status'.  You get instant list of
modified/scheduled things.

If youw want to see what 'svn up' *would* modify, without actually
updating, run 'svn status -u'.  It's the same as 'svn status', except
that it contacts the server and adds little asterisk marks next to every
file which is out-of-date.  If you see a "*" and "M" on the same file,
it means you're in for either a merge or a conflict.

(FWIW, the --dry-run flag only exists for 'svn merge'.)



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org