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

[Ling Lo]

On 1/7/08, Frank Compagner <frank.compagner at guerrilla-games.com> wrote:
>
> IW> I would think, given this is a rather special case, it would be
> IW> best dealt with by creating a custom client - using either an API
> IW> or commands - that did the necessary manipulations to make it
> IW> happen in a way the server could accept without modification.
>
> Yes, sure, I'm not asking to any fundamental changes to the Perforce
> branching mechanism. We already do a lot of custom tool development to
> make Perforce a bit easier for our non-technical users, we're figuring
> out how best to integrate branching into them. With a bit of luck we
> only need some small changes to make switching branches a bit more
> practical.

I was just thinking about whether implementing svn switch as a tool
would work.  Sync -k would cover the easy part.  Figuring out the
difference by getting the checksums of all the files in a branch and
comparing them with another branch is also easy enough with fstat.
Would it then be possible to efficiently force sync the practically
random selection of files?

> >> but if the local files that do not differ between the branches
> >> remain untouched only a partial build will be necessary.
>
> IW> There are build managers that can make decisions like that based
> IW> on the file's content rather than a time stamp. That wouldn't
> IW> solve the re-sync problem, but it would cut the subsequent build
> IW> times.
>
> Won't that make the up-to-date check prohibitively expensive? Then a
> build where only a single file was changed would still need to check
> every single file to know it was done.

I've found this to be true for an asset build system where the input
files mounted to gigs.  In the end, I settled for something that used
timestamps inequality (not greater than) to figure out whether or not
to checksum.  Admittedly the first run would be very slow but it was a
balance between speed and reliability.  In hindsight, timestamp
inequality would have been sufficient since the OS retains a 64-bit
timestamp.  The checksum was just icing for caching object files on a
network share.

But anyway, I'm digressing from the purpose of this mailing list.

Cheers,
Ling