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

[Ivey, William]

> 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.

Are you sure? My personal machine has about 2.5 TB hung on it and
that cost less than $1000. (I work with a lot 90+ Megapixel photos
at home.)

If you have a lot of files that don't change, perhaps the solution
is to reorganize the projects to isolate relatively stable blocks
of data in their own projects. (You could do this client-side, as
well, by using two+ clients, carefully adjusting the views to
coexist properly. One client would represent stable files, while
the other(s) would replace the branch-specific files.)

> 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.

Only if it didn't impact speed or reliability for the more general
situations.

I would think, given this is a rather special case, it would be
best dealt with by creating a custom client - using either an API
or commands - that did the necessary manipulations to make it
happen in a way the server could accept without modification.

> but if the local files that do not differ between the branches
> remain untouched only a partial build will be necessary.

There are build managers that can make decisions like that based
on the file's content rather than a time stamp. That wouldn't
solve the re-sync problem, but it would cut the subsequent build
times.

-Wm


-----Original Message-----
From: frank at compagner.com [mailto:frank at compagner.com] 
Sent: Friday, January 04, 2008 5:52 PM
To: Ivey, William
Cc: Perforce Users
Subject: Re[2]: [p4] How do YOU identify the code set for a release?

>> 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