On Tue, Feb 12, 2002 at 12:34:28AM -0500, Daniel Berlin wrote:
>...
> > 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
> standard).
> There is no easy replacement in 3.0 or any other compiler, so we can't
> do it that way.
Huh? There isn't a way to take a FILE* and create a C++ stream? That just
seems weird; like it is a total disregard of interfacing with existing
software(!).
How about wrapping a stream around a file descriptor? We can get a file
descriptor from (most) Python file objects.
> So I changed rcsparse and friends to just pass the filename, and removed
> supporting passing in fileobjects from tparse.
Hmm. Well, if we can't portably convert a FILE* or file descriptor into a
stream, then we can certainly remove that capability. I'd like to keep the
general ability of passing a file object.
In any case, it sounds like *some* kind of patch is required for 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.
Huh? If there are different authors, then how could it possibly be the same
commit?
And how do you manage to give different log messages in one commit?
Even if both of those are possible in CVS, we don't have the equivalent in
SVN. Those would need to be partitioned (as appropriate) into multiple SVN
commits.
> Think what happens when we wind up with the case of two
> revisions to the same file in one commit.
Huh? That shouldn't happen. It does now because we don't have enough smarts
in there right now.
Oh. Hmm... does this happen if you commit to multiple branches at one time?
e.g. a change to HEAD and a change to a branch? We should be able to do the
same in SVN, but we'd need to first map the branch portion(s) to their
alternate, branch paths. Then we could commit changes to the trunk and the
branches all in one shot.
Outside of that case, we should not have multiple CVS revisions on a single
branch participating in a single SVN commit. That would, effectively, lose
the two-revision information.
> > > + 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.
Note that "yet" in there. The original code was set up with the intent to
set the "target" parameter to the convert() function. The patch you provided
used an approach that I wasn't quite happy with, so I didn't do it. That's
all. Not like the concept entirely is rejected. Just that we got the bulk of
your work checked in, and now have some additional tidbits to do in
additional passes (such as the log cache, those tweaks to BuildRevision, and
this target stuff).
I saw your followup patch for the target; it looks good, so I'll apply the
bugger...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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