> > 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.
It's actually more in the "life saver" category than just "useful" for us.
> However -- I use Perforce on a project where some generated files
> are also kept in the repository. That's means that when those files
Well, that's your problem right there :-)
> 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
You can have the generator opening the file before generating it.
Or you can have your make target open this file before calling the
generator.
> 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.
But that requires statting everything. That's fine for a small project.
It's not fine for a large project. CVS doing the same thing was killing
us two years ago, and the project has doubled in size since then --
without p4, it wouldn't have been manageable.
Note that Perforce CAN work in the mode where you change wherever you
want and then it figures out what to do. At the root, "p4 edit ...".
Then, before check-in, "p4 revert -n" to revert anything that didn't
change. However, this mode reduces perforce to the sloth of CVS.
> > 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 ?
I think it doesn't have to. It would be useful to just warn you if the
file is out of date, but that warning can only actually be implemented if
there is an online repository to check against.
> > 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
The feature that perforce will let me commit in 0.1 seconds instead of
crawling my disk for 10 minutes trying to figure out what's open is very
very nice. The feature that perforce will just send me the updates I need
when I sync, without having to crawl the disk to figure out where I last
updated each directory is very nice (although this could be done in SVN
too).
To put it another way: the keeping of state telling the system which files
are actually open (and the general status of each file) in a place where
getting at it is "instantaneous" accelerates working on large code bases
by order(s) of magnitude. Perforce does this server-side. I think that most
of the benefits could be had by doing it client-side, too, which would fit
better in the SVN model.
Cheers,
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 27 20:32:02 2002