"Jon Watte" <hplus@mindcontrol.org> wrote:
> I actually don't care too much about the "extra" copy of each checked
> out file (disk is cheap!). However, I like working in a command-to-edit
> mode, because it allows the source control system to know what it needs
> to inspect for "diff" or "checkin" operations -- only actually edited
> files are actually considered; no stat-ing of 18,000 files just to
> figure out what to do.
Yes, for performance reasons that could be useful.
However -- I use Perforce on a project where some generated files
are also kept in the repository. That's means that when those files
are to be regenerated, we've to p4-edit them before running the
generation program. And it's possible to leave a file out (in this case
the generation program fails, because the file is readonly), or to
p4-edit a file that won't be modified. I like the way svn figures
out by itself the set of files it has to commit.
> Note that the "edit" operation COULD be done off-line in Subversion,
> because you already have the file, and SVN likes to keep client-side
> state (Perforce doesn't). However, when on-line, it would be useful if
> you got a warning if the file you're editing is newer in the repository.
svn status -u ?
or should the hypothetical "svn edit" command have a -u switch to update
the file before marking it ready for edition ?
> This is, in my opinion, one of the better features of Perforce (together
> with bunched atomicly commited change lists).
I don't see how the perforce changelists are better than svn's ones (but
you're probably referring to a p4 command I don't know.) With p4 you
got the changelist for your whole client view. "svn log" gives you the
change log for a file or a subdirectory as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 27 11:06:15 2002