Blowing away file revisions?

[ScottBlachowiczsab at seanet.com]

> Normally that would be fine (even expected/required), but
> this is a binary file, so the whole file is stored on the
> server for each revision and it can get kinda wasteful to
> do that kind of stuff...especially when I know immediately
> after submitting the bad version that it is bad (and there's
> nothing dependent on that version).

I DID get one suggestion...that maybe 'p4 edit -t tempobj' could help.  And,
I think it could for my purposes.  I was thinking that I could keep all of
the files in my directory of pre-built binaries as 'tempobj' files, so that
only the latest revision of the file contents is retained along with all of
the history info.  That way, it'd be a pretty low cost process to replace
the binaries.  If I've run them for a while (or released them to someone or
whatever) and feel it's worth it, I could copy them over to non-tempobj
files to retain their contents as well.

Has anyone here fiddled with 'tempobj' files much?  The question I had is
whether I should use 'p4 integrate' to do the copying and if the "lazy
copying" would be a bad thing with files whose earlier versions disappear?

	cd .../bin
	# rebuild foo
	p4 add -t tempobj foo
	p4 submit foo

Now, foo#1 exists. Then, save a copy over to the bin-save directory

	p4 integrate ... ../bin-save/...
	p4 submit

So, bin-save/foo#1 refers to bin/foo#1.  I suppose the file type would carry
over...should I then change it back to binary in the copy?

	p4 edit -t binary ../bin-save/...
	p4 submit

I suppose that would make a bin-save/foo#2? Would there be an actual copy
there now? Or would it still lazily point back at bin/foo#1?

	p4 edit foo
	p4 submit foo

What about now?  There shouldn't be any bin/foo#1 any more, but
bin-save/foo#1 refers to it.

Does that make sense?  I should probably just try it all out and see how it
works...but there's too much real work to get this week before my looming
deadline...

- --
Scott Blachowicz
<sab at seanet.com>