Greg Stein wrote:
> However, both approaches will not scale properly. It seems that you'll be
> creating keys for practically every file *and* revision that is found in the
> conversion process. That isn't going to work :-)
Forget all about that. It works, but I am now working to save stuff to
intermediate file.
>>...
>>@@ -315,12 +386,14 @@
>> for f, r in self.changes:
>> # compute a repository path. ensure we have a leading "/" and drop
>> # the ,v from the file name
>>- repos_path = '/' + relative_name(ctx.cvsroot, f[:-2])
>>+ base_name = get_branch_path(ctx, f, r)
>>+ repos_path = base_name + '/' + relative_name(ctx.cvsroot, f[:-2])
>> print ' changing %s : %s' % (r, repos_path)
>> for f, r in self.deletes:
>> # compute a repository path. ensure we have a leading "/" and drop
>> # the ,v from the file name
>>- repos_path = '/' + relative_name(ctx.cvsroot, f[:-2])
>>+ base_name = get_branch_path(ctx, f, r)
>>+ repos_path = base_name + '/' + relative_name(ctx.cvsroot, f[:-2])
>
>
> These changes, where the base paths are set, would be good to have a
> separate patch; we could get that applied straight away.
OK. I'll try to make it later today.
>>...
>>@@ -444,6 +519,87 @@
>> print ' CONFLICTS:', `conflicts`
>> print ' new revision:', new_rev
>>
>>+ # make a new transaction for the tags
>>+ rev = fs.youngest_rev(t_fs, c_pool)
>>+ txn = fs.begin_txn(t_fs, rev, c_pool)
>>+ root = fs.txn_root(txn, c_pool)
>>+
>>+ for f, r in self.changes:
>>+ tag_key = get_key(f, r)
>>+ if g_tags.has_key(tag_key):
>>+ for tag in g_tags[tag_key]:
>>...
>>+ fs.copy(t_root, repos_path, root, tag_path, f_pool)
>
>
> This algorithm implies that each and every file within a specified tag
> directory originates as a copy from somewhere else. That is, if you have
> 100,000 files in your CVS repository, and you have 100 tags, then you are
> constructing 10 million copies in the SVN repository.
Yes :(
> While SVN might (technically) be all right with that, I find it to be a bit
> less than ideal... (I have this bad feeling that certain types of log
> operations, or tracking change history, or something might be adversely
> affected).
>
> I believe the right approach to generate a tag is to find the single SVN
> revision that most closely matches the set of files/revisions specified by
> the CVS tag. Hopefully, that would be one revision. But since it is possible
> that a CVS tag can be arbitrarily composed of files/revs from various points
> in time, this won't always happen. For these cases, then the ideal is to
> find the fewest number of copies of files/dirs/revs to construct a tag, and
> to commit that.
I agree.
> I'm not entirely sure what the algorithm is, but part of the reason for the
> multiple passes is to enable analytic processes like this, yet avoid a huge
> monolithic operation.
Yes. I will try to think up a pass that would optimize this.
MArk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 07:44:15 2002