cmpilato@collab.net writes:
> > + 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?
The subversion 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
> by "adjust"?
The range of svn revisions from which this parent could be copied and
still catch everything underneath it correctly.
Adjusting is the process of narrowing the endpoints as paths
underneath the parent restrict the range more and more.
> > + 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:"
> loop?
I don't think it matters whether they get created on demand, or in
advance. If it's not there when we need it, we just create it.
> > +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 will be outputting a revised .commits file that contains the new
copy revisions. It will replace the previous .commits file.
> > +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,
> too often.
Doesn't matter how often they do it, we still have to write the code
for it :-(.
Do these answers help? (I'll work them into the document when I get a
chance.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 21:11:46 2003