[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 14:02:40 CET

On Mon, 11 Feb 2002, Greg Stein wrote:

> 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?
Well, no *standard* way.

basic_filebuf in libstdc++-v3 generally takes a FILE * as its first
But it's not pretty, or guaranteed, just luck.

Look in the "added members and types" section of libstdc++-v3 faq.

> That just
> seems weird; like it is a total disregard of interfacing with existing
> software(!).

Don't look so surprised. iostreams = good, stdio = bad, remember?

One of the largest complaints you'll always hear from C++ people is that
books on C++ don't teach iostreams, they use C stdio.

> How about wrapping a stream around a file descriptor? We can get a file
> descriptor from (most) Python file objects.

Nope. The suggestion in the libstdc++-v3 docs is to fdopen it and abuse

> > 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.
So would I.
In fact, this completely took me by surprise when i tried to compile
tparse with g++ 3.

Attempts to find a solution have been generally met with "Just use
ifstreams". E

> 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?

By abusing the way you digest.
(Sorry, that just sounds funny to me.)
> 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?


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.