On Wed, 2003-09-17 at 23:28, Ben Collins-Sussman wrote:
> Kirby Bohling <kbohling@birddog.com> writes:
>
> > To state the obvious: how hard would it be to write a program that reads
> > the svn dump files and build the indexes "the RCS way"? That would seem
> > the obvious approach to do this.
>
> Well, um... you're describing a svn2svn script. Convert an SVN
> dumpfile into a genuine CVS repository. Then let WinCVS display RCS
> history all it wants!
>
> Should be much, *much* easier to write than cvs2svn script we have
> now. No need to "deduce" changesets or branches or tags at all.
That's not really what I meant; however, it's not a bad idea,
especially as it's a two birds for one stone deal in the short term. I
meant how hard would it be to write a tool that creates the data
structures that make the problem easy (which you answered: not nearly as
hard as cvs2svn).
When I said "RCS Way", organizing the data so it is like this
node: { set of revisions the node changes in },
....
node: { set of revisions the node changes in }
instead of the "SVN Way"
revision: { set of nodes changed in a given revision },
...
revision: { set of nodes changed in a given revision }
Sorry for the rough analogy, and crappy "diagram", I know the
subversion diagram should be more complex. To the best of my
understanding that is the crux of the problem.
My concern about running svn2cvs, then WinCVS would be simple stuff
like, file moves being lost, directory moves being lost. The meta-data
that svn captures that would be lost in the conversion to back cvs.
However, from your description, if you had the svn2cvs and the WinCVS
display history code, you might be able to jigger them together so the
meta-data svn has isn't lost.
Of course, displaying the history could be tricky, because do you
display the history by following the node history, or the history by
following the path history. I hate that complexity about SCM problems,
it makes everything more so much harder. Oh well, I get well ahead of
myself thinking further then I'm ever going to code.
Kirby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 19 01:54:23 2003