[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH]: Revised cvs2svn.py patches

From: Daniel Berlin <dan_at_dberlin.org>
Date: 2002-02-12 06:34:28 CET

Just a note or two... (THe rest of the stuff are things i meant to do
anyway as cleanup, i just hadn't gotten around to it yet)
> I didn't see the point of this change, so I left it out.
> I'm guessing it is to make it easier to substitute different parsers in
> there. Lucas Bruand just made some change in the ViewCVS repository that
> might help with parser substitution (although I haven't reviewed what he has
> done yet).
It won't help.
See, he's using istdiostream, which only exists in GCC 2.95 (it's non
There is no easy replacement in 3.0 or any other compiler, so we can't
do it that way.
So I changed rcsparse and friends to just pass the filename, and removed
supporting passing in fileobjects from tparse.
> The above code is all gone now. Rather than once per file, at the end of the
> commit processing, I call a new function (get_metadata) to fetch the author,
> log message, and formatted date. At the moment, there is no caching, but we
> can add it to that one method.

I had already done the same, but the comment in the checked in version
is plain wrong the log message isn't always the same for every cvs
revision in a commit. Nor is the author, for that matter.
Think what happens when we wind up with the case of two
revisions to the same file in one commit.

> > + opts, args = getopt.getopt(sys.argv[1:], 'p:h:v')
> Not doing this (yet?).
Errr, you could have just changed it to set the SVNROOT variable instead.
It's intended to be the home of the new repository.

Right now, you always create it named "svnroot", which is a real pain for
testing conversions.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.