On Mon, 2003-03-17 at 22:52, Karl Fogel wrote:
> Yah, I added it only for compatibility (since Todd said he had it
> hardwired, I thought maybe he wasn't the only person).
>
> But the general feeling seems to be that it's ugly. And I have to
> agree: it's confusing syntactically with `pget', and semantically with
> `cat'. Not such a good idea, really. I'll revert.
>
> Todd, hope your feelings won't be hurt :-).
My feelings definitely won't be hurt as long as the license isn't
changed to say I can't keep the modification in my local tree. :)
I mentioned it on #svn, and someone else seemed interested, so I sent it
to the list. I'm not demanding its addition. I've had it in my working
copy for a couple months, and I don't have a problem leaving it there.
As far as my 2 cents on command naming. In environments where files
have to be specifically 'locked' or 'reserved' before editing, you
initially 'get' a read-only copy of the tree, and in order to edit it
you 'check [it] out', which marks it as reserved for editing in the
repository, and makes it writable in your working copy. Since svn and
CVS don't use such a process(at least by default in CVS), a 'get' and a
'checkout' become equivalent. Of course, this is how I've always
associated it in my head. Then again, my first experience with source
code management was SourceSafe (before they were bought out by M$), so
I'm probably permanently brain damaged in this area. Also, 'co' never
stuck as an alias for 'checkout' for me, and get is much shorter than
checkout, which is probably the main reason I've always used it with
CVS.
--
Todd Mokros <tmokros@neo.rr.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 18 06:41:33 2003