> Modified: trunk/tools/cvs2svn/design-notes.txt
> --- trunk/tools/cvs2svn/design-notes.txt (original)
> +++ trunk/tools/cvs2svn/design-notes.txt Wed May 28 01:08:09 2003
> + for each branch:
> + Look up the subversionized <path> in branches/<branchname>.db
> + If not present, then initialize with list `(this-rev)'.
> + Else if present, error -- branches can't be created twice.
What is "this-rev"? The Subversion revision? The CVS file revision?
> + Then bubble up up subversionized <path>'s parents:
> + If present, adjust the range of possible revisions
What range? No range has been mentioned so far. And what do you mean
> + Else if not present, add, with revision `(this-rev)'.
> + (We could keep scores for different ranges, but that vastly
> + complicates things... Let's get the simpler algorithm working
> + first, since it's really a subset of the score-keeping one
> + anyway.)
> + Look up the subversionized <path> in every other branches/*.db:
> + If present, set range endpoint, so we have `(revA revB)'.
> + Else if not present, do nothing.
Do the .db files for *all* branches exist (or need to exist), albeit
without any content, before we begin the above "for each branch:"
> +Now we can make a second pass over the commits file, this time looking
> +up tags and branches in their DBs. For each one we can find a decent
> +set of mkdirs and copies -- not always the ideal minimal set, but in
> +most cases it should be close. It will tend to do copies of whole
> +directories or directory trees the farther down it goes, so the danger
> +lessens as we approach leaf nodes, which is good.
And where in the list the Subversion revisions will we squeeze in
these branching/tagging operations?
> +We'll have to make N passes total, in order to handle branches off of
> +branches (N being the max branching depth).
Yucky, but hopefully people don't branches their branches too deeply,
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed May 28 19:10:22 2003