On Wednesday 16 March 2005 10:25 pm, Kevin Puetz wrote:
> Steve Seremeth wrote:
> > 1. Expected "ballpark" performance information would be very helpful in
> > the FAQ. Other SCM systems might not be any better on this front, but
> > if we had known upfront what this was going to be like we might have at
> > least organized our repository (and subsequently, our build scripts)
> > differently.
>
> The only thing I can think of is that a lock/unlock SCM might be able to
> assume that files which you did not lock cannot be modified, so it would
> have less to scan. Of course, if it made this optimization, it would
> silently miss anything that you edited locally when you weren't supposed
> to.
That's how Perforce handles things. A typical Perforce workflow goes
something like the following:
- Checkout. All files are marked read-only.
- User A asks Perforce server for permission to work on file A. If file A is
not locked, server grants permission. Client changes file from read-only to
read/write and adds file to default changeset.
- User A ask to work on file B. Client changes file to read/write and adds to
default changeset.
- User A asks server for an exclusive lock on file B. Server checks if anyone
else is currently editing file B. If not, exclusive lock is granted.
- User A finishes making their changes and commits the changeset. Client
_only_ examines the files the user asked to edit and commits the ones with
modifications.
The downside is that Perforce assumes you are always connected to the server.
You cannot work in a disconnected environment. However, since you explicitly
ask to edit files, the client knows which files you are working on which
leads to extremely fast commit times.
The other cool idea Perforce employs is the concept of creating local
"changesets", which are simply groups of files you are currently editing. By
default, when you edit a file, Perforce places the file in your "default"
changeset. However, you can "move" the file into a different local
changeset, if you desire. When you perform a commit, Perforce defaults to
committing only the default changeset. This allows you to start work on one
project. Then, say you make a small bug-fix in another project, you can
easily commit those changes _without_ accidentally comitting any other
changes.
Neat stuff.
-Sean
------------------------------
It is hard to understand how a cemetery can raise its burial costs and blame
it on the higher cost of living.
------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 17 16:42:07 2005