Configurable target directories

[Toby Johnson]

Dirk wrote:
>
>>>> For example we could accept a "directory map" input file such as:
>>>>
>>>> ${ROOT} = /trunk
>>>> ${LABELS} = /labels
>>>> ${ORPHANS} = /orphan
>>>> /projects/Website1 = /trunk/web/site1
>>>> /projects/Website2 = /trunk/web/site2     
>>>
>> It would need to be a strict string replace anchored to the beginning 
>> of the path string, otherwise it would be impossible to be sure that 
>> there are no overlapping targets. And we can't have overlapping or 
>> duplicate targets because it would completely throw off the internal 
>> state tracking and sanity checker for individual items.
>>
>> Of course if it didn't require that the mappings must match path 
>> boundaries then your example would still work. In other words we're 
>> talking about a simple s/^$from/$to/ without needing to check whether 
>> the "from" grabbed an entire folder name or just part of one.
>
> Huh, tough task. My change was rather simple compared to this, since I 
> only renamed the physical root record "AAAAAAAA" [1] during the 
> conversion. You are more looking for a search and replace within the 
> converted VssAction history. Why not. So one have to assure, that the 
> problematic actions like rename, branch, archive and so on does not 
> mess up with this. Intermediate missing directories are created on the 
> fly. But I would still stick to do the first 3 (ROOT, LABELS; ORPHANS) 
> during the conversion, and only to do some logical rearrangements 
> after the ActionHandler.

Yes, that's what I had in mind. The "correct" path would be used for all 
internal use, such as renames and branches, and the path is only 
converted at the very end after the other determinations have been made. 
So it's really more of an operation on the dumpfile itself, than on the 
actual VSS paths.

toby