The pain with 'mark for edit' is that it means there are steps between you
and your goal; you think about a change, you start to work on it and - oh,
the file is read only. Let me go play with a tool to tell it what I plan to
do, so I can actually put my ideas in motion.
If the Perforce administrator doesn't have exclusive locks, I almost always
keep the entire repository checked out, then select 'revert unchanged files'
before doing a commit. Meaning, there is no speed benefit for me whatsoever;
in fact, file comparisons for such a revert require communication with the
server, while such an equivalent would be local disk IO only on subversion.
This is better than being in an airport and realizing I don't have all the
files needed checked out, and having to do hacks like manually marking files
read-write and then twiddling with tools after the fact to get those changes
recognized.
I kinda like git's 'staging' concept; all files need to be marked as part of
a commit, whether they are brand new files or existing files which have been
modified. the 'status' command will report on staged and unstaged files the
same. You still need to check files before you overwrite them with newer
versions to keep updates from being destructive.
-David Waite
On 9/30/07, Greg Hudson <ghudson@mit.edu> wrote:
>
> On Sun, 2007-09-30 at 20:35 -0700, Jared Hardy wrote:
> > One feature I forgot to mention, that has come up in previous WC
> > refactoring threads, was a "mark for edit" command. This is similar to
> > the Perforce "checkout" command -- their "update and get lock"
> > equivalent, since all Perforce WC files implicitly require locks. This
> > would allow clients to bypass recursive disk IO status comparisons,
> > when listing modified files.
>
> Yeah... I think the general consensus is (or would be, if people thought
> about it) that "mark for edit" would produce wonderful speed for
> recursive WC operations, and wouldn't be a hassle when you're using an
> editor with a well-integrated svn mode, but would be a horrible pain in
> the butt when you aren't.
>
> I think if there were a WC design which made "require mark for edit and
> get better performance" a checkout option in some beautiful elegant
> fashion without unduly complicating the code base or UI, that would be
> the best of both worlds. But that feels a bit blue-sky.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Mon Oct 1 07:16:24 2007