[p4] How do YOU identify the code set for a release?

[frank@compagner.com]

>> With Subversion, I can create the branch then switch my local
>> working copy from trunk to the branch in just a few seconds, do
>> the build, then switch back to the trunk.

IW> It's even faster when you have both branches resident on the
IW> machine all the time. In fact, you can build both at once,
IW> tools permitting. (I usually have four or five branches of our
IW> product synced at one time since I have to work on and build
IW> all the currently supported versions. Changing the "identity"
IW> of a single directory would be a nightmare.)

IW> It's a one time expense in terms of time, and disk space is
IW> cheap.

Well, that isn't always true. The size of a full head revision of
our main project is currently about 150GB. Add to that the temp
files needed to make a build and it's over 250GB. With these amounts
of data it does become a bit unpractical to keep several branches live
on your local machine. And as several Gigabytes of data are checked
into each branch every week keeping them in sync isn't exactly cheap
either.

IW> You can "fake it" to make what you're used to happen by playing
IW> games with your client mapping or with symbolic links if you're
IW> using a Unix system, but it's not as safe and convenient as
IW> one directory per branch.

It would be great if their was a reliable and cheap way of changing
branches in-place on the client, where only the files that are
actually different between the branches are downloaded. This would
also help a lot in reducing build times after switching branches. A
full build takes several hours, but if the local files that do not
differ between the branches remain untouched only a partial build will
be necessary.

As it is, you can sort of fake it with a change in the client mapping
followed by a sync -k, but you would still need to do at least a
diff -se to get the list of changed files. As that means calculating
an md5 hash (or something similar) of all files in the entire branch
this can easily take hours. It would be great if the hash values could
be cached locally on the client (they are now cached on the server,
which helps a lot at that end). That way a simple check against the
atime would be enough to see if the hash needs to be recalculated.
Another idea would be to expose the hash function in the p4api (maybe
through a FileSys::GetHash() function), that way we could make a
custom tool to manage the hash cache ourselves. When combined with a
filesystem hook to trap filewrites to the branch directory this might
make switching branches on a project like this a much less painful
operation.

----------------------------------------------------------------
Frank Compagner                                  Guerrilla Games