At 08:49 AM 10/23/2002 -0400, Schipper, Martijn (Contractor) wrote:

There's a question at the end of this e-mail that I'd ask first.

Okay...

I think I'd handle it as three operations: 1. Backup everything in sight, checkpoint first then backup and put it somewhere "safe". This operation you're asking about has a high probability of "oops!" for various reasons. 2. Obliterate the thing you don't want, to make it go away completely and utterly. 3. Read the technical notes on how to rename a branch doing checkpoint surgery, because you're trying to do the seamless version that looks like it was always named "foo". Personally, I'd use "p4 integrate foo2/... foo/... ; p4 delete foo2/... ; p4 submit" to do it, because it leaves enough information lying around to know what happened, and then "p4 filelog -i" and "p4 changes -i" will still tell you old history. (With this method, the obliterate isn't necessary; a careful inspection, of files/filenames in foo/... to make sure that the older filenames from the previous foo/... aren't hanging around, is necessary and you might need to delete some of the older filenames in foo/... by hand.)

Now, the question:

Why? This is circumventing the librarian, and its job is to "remember everything". Isn't it better to know that foo2 existed, and what was checked in and where? There might be scripts, makefiles, etc, that know about foo2 and renaming the files won't change the CONTENT of those build scripts. They'll fail with either method until modified, but if you use the obliterate/checkpoint-surgery method you'll have headaches because people might have foo2/... on their client workspace and it's not erased/gone [from those client workspaces] after you'd finished.

In general, think of "obliterate" as being the tool for correcting mistakes VERY QUICKLY after they are made, not a few days/weeks/months/releases later to clean things up.

-Jeff Bowles