6 messages in com.perforce.revml[revml] Re: Some issues/thoughts| From | Sent On | Attachments |
|---|---|---|
| Matthew Attaway | 23 May 2001 13:39 | |
| barries | 23 May 2001 17:00 | |
| barries | 23 May 2001 19:52 | |
| Matthew Attaway | 23 May 2001 19:57 | |
| Matthew Attaway | 24 May 2001 00:06 | |
| barries | 24 May 2001 04:35 |
| Subject: | [revml] Re: Some issues/thoughts |
|---|---|
| From: | barries (barr...@slaysys.com) |
| Date: | 05/23/2001 05:00:00 PM |
| List: | com.perforce.revml |
On Wed, May 23, 2001 at 01:39:22PM -0700, Matthew Attaway wrote:
Hi Barrie,
Only two things have come up so far in this round.
Very cool, thanks for testing it!!!
First off, vcp doesn't fail gracefully. Down below I have the output of an attempt to translate a Perforce label into cvs tag, but due to the fact that the label starts with a number it fails the translation. Instead of either balking and dying, or squawking and moving on, it starts this series of "not deleted" statements. A more graceful failure would be nice, and slightly less nerve wracking.
There was "nice" message at the top from cvs, but that would be off the screen before you blink. The undeleteds are the equivalents of assert()s in there to tell me when I didn't sweep up and turn the lights off before leaving. We can clean that up nicely. >>TODO
often that not. Right now the Perforce converters append underscores to the front of the name and swap out bad characters with underscores. I haven't tried a cvs->p4 conversion yet, so maybe it already does this.
There's some underscorification in there, but not enough. >>TODO
If nothing else this is just reminder to future dest/source module writers to take this into account. =)
Present and future. Will do. Also, spaces in filenames are an issue in some places.
I was thinking late last night, and realized the big difference between the current Perforce converters and vcp is that the current converters attempt to create changelists out of the metadata, whereas I don't believe vcp does.
It should: it sorts all revs and then watches for changes in metadata or seeing a second rev of a file before doing a p4 submit.
Is that something module writers would put in the source mod, or would that be a dest mod thing?
It's implicit in vcp itself: every source filter gives the dest filter a chance to sort the revs before starting to send them over the fence:\
sub copy_revs { my VCP::Source::cvs $self = shift ;
...snip grabbing all of the cvs metadata into $self->revs & co. ...
$self->dest->sort_revs( $self->revs ) ;
my VCP::Rev $r ; while ( $r = $self->revs->shift ) { $self->get_rev( $r ) ; $self->dest->handle_rev( $r ) ; } }
See VCP::Dest, the rev_cmp_sub entry for default sorting details. Then you can see the source code in VCP::Dest::p4 for change aggregation logic.
- Barrie