2 messages in com.perforce.revml[revml] Fwd: Re: breaking up long com...| Subject: | [revml] Fwd: Re: breaking up long command lines.... |
|---|---|
| From: | barries (barr...@slaysys.com) |
| Date: | 07/19/2001 11:26:40 AM |
| List: | com.perforce.revml |
[Cced to list with permission]
On Thu, Jul 19, 2001 at 10:51:36AM -0500, david d zuhn wrote:
When I get that done, I'll roll another release.
Well, I didn't get to this patch before the 0.2 release, so I used that instead.
The same command as before, with the same CVS repository, worked just fine with 0.2.
Very cool. My curiosity is getting the better of me:
How large was that repo? 6800 files?
How many revs got condensed in to how many change numbers?
Are you confident that VCP didn't bollux up the transfer some how, and that the change number aggregation was appropriately done?
Don't go doing a bunch of work to figure all those out, I just want to know what VCP has been used succesfuly for, as I'm sure the good folks at Perforce would like to.
Does this:
link() now succeeds when going from cvs->p4
mean that the TMPDIR issues I raised are null and void?
I hope so, tested it here, but that's not a guarantee :-).
And I'm presuming that nothing in 0.2 resolves the pathname issues that we've talked about. Nothing in the notes looked like it referred to this.
The crytpic note about an improvement to deduce_rev_root is what covers that fix. It's still not quite all there, since it makes assumtions because it can't test the dir-ness of the specs like Unix's cp command can:
Spec rev_root ================= ======== foo:/bif/bam/boom /bif/bam/boom (assumes boom's a dir) foo:/bif/bam/boo* /bif/bam (assumes that boo* leads to multiple files in /bif/bam)
I think I want to sharpen the the logic by checking to see if more than one file is retreived, so the first examples might result in
Spec rev_root ================= ======== foo:/bif/bam/boom /bif/bam/boom (if boom's not a file) foo:/bif/bam/boom /bif/bam (if boom's a file) foo:/bif/bam/boo* /bif/bam/boom (if boom's a file or dir) foo:/bif/bam/boo* /bif/bam (if both boom and boost, say)
All of this ASSuming can be overridden with the -r option, but I want vcp to Do The Right Thing most of the time. I definitely need real-world feedback on this, which is why I'm tweaking rather than revamping.
I also need real world feedback on the way VCP::Dest::p4 coopts and restores or deletes client specs: is it better to not delete them ever, or to not restore them? Is there any reason to want a client spec that merely points at a no-longer-there tmp dir?
What's your geographic location? I need to know where I buy you the tall cold one.
Pittsburgh, PA, USA. Tall cold ones always welcome :-). But I hasten to point out that Perforce buys me the tall, cold ones for this work, so thank Christopher Seiwald, Kathy Baldanza, Matthew Attaway, Jeff Anton and others who advise and test (forgive me if need be, as I forget names).
- Barrie
----- End forwarded message -----