Branko Čibej <brane@xbc.nu> writes:
> * cvs2svn (or any other conversion) can delay branch and tag
> creation, and optimize them better
> * merging repositories or importing (via svnadmin load) some
> project's history
>
> In both cases the you'd typically ise date-range queries on a path
> where locally the revisions are ordered, and therefore the
> intersection of changes and dates is a continuous range of revisions.
>
> >I remain convinced that enforcing date order is the only sane path to
> >follow.
>
> If we keep that restriction, there's no way optimize cvs2svn, which
> means that people who start with a converted repository will keep
> complaining about the size blowup.
What is the proposed optimization to cvs2svn here?
Since branch and tag creation are not versioned operations in CVS,
cvs2svn is free to put any date it wants to on the SVN revisions used
for those creations. "Any date it wants to" within the bounds of
reason, of course -- the bounds of reason being too complex to go into
here, unless you really want the gory details. But in any case, I
don't know of a way that enforcing or not enforcing ordered dates on
SVN revisions affects cvs2svn optimization.
> Not to mention that it takes a single SQL query. But it might be a bit
> hard to do in libsvn_fs_fs, I imagine. :-)
Dang, that was cruel :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 26 17:45:52 2004