On 10/1/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> At Google when I was there, p4 edit took ages - into the order of
> minutes - to permit writeability for a single file - it's certainly
> not a unnoticable operation. Admittedly, it may have been because of
> the way p4 was configured at remote offices. Though, I don't recall
> 'p4 edit' being particularly fast in Mountain View either. I do
> recall that 'p4 opened' was *way* *way* slower than 'p4 edit' - that
> was even more annoying as it was impossible to quickly discover what
> files you had opened for edit! Our team would schedule coffee breaks
> and/or Nerf fights around p4 commands. =P
Sure, but the Google p4 experience isn't typical: thousands of
engineers over many remote offices, with 10's of thousands of working
copies all being tracked by the server. It doesn't scale, period.
That's why we're investigating subversion.
But if you use perforce as it was intended -- a small-to-medium sized
team on a single fast LAN -- you can bet that 'p4 opened' ('svn
status') is crazy fast. I've seen it.
> Setting aside the performance aspect, based on my own experiences with
> Perforce, I'll strongly disagree that *mandatory* 'svn edit' is a
> feature we would *require* everyone to follow. The required workflow
> change is simply not something I'd want to impose on everyone.
> Optionally? Sure - if you have a large enough working copy and/or you
> don't mind altering your own workflow. But, I think there are many
> many users who would find 'svn edit' mandatory a huge turn-off -
> especially given where we've come from.
I think everyone agrees that if we implement 'svn edit', it's going to
be an optional thing. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 1 19:02:11 2007