You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2003/05/28 17:09:59 UTC
Re: svn commit: rev 6076 - trunk/tools/cvs2svn
kfogel@tigris.org writes:
> 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
by "adjust"?
> + 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?
> +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,
too often.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6076 - trunk/tools/cvs2svn
Posted by cm...@collab.net.
kfogel@collab.net writes:
> 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.
[...]
> Do these answers help? (I'll work them into the document when I get a
> chance.)
The answers that I didn't already know were helpful, yes.
Sorry, I should have mentioned that most of my questions were intended
just to drive you towards making the document more clear (for others
who weren't privy to our whiteboard discussion yesterday).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6076 - trunk/tools/cvs2svn
Posted by kf...@collab.net.
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