On Tue, Apr 24, 2001 at 11:58:43AM -0700, Greg Stein wrote:
> On Tue, Apr 24, 2001 at 01:13:35PM -0500, Sam TH wrote:
> > On Tue, Apr 24, 2001 at 11:49:16AM -0500, Karl Fogel wrote:
> > > Sam TH <sam@uchicago.edu> writes:
> > > > > Euh... we aren't going to parse Entries files. That is a client-side thing.
> > > > > We're just going to crawl through the ,v files on the server.
> > > > >
> > > > > I'm not sure that our testing system, nor cvs2svn would need this. Did I
> > > > > miss something?
> > > >
> > > > I figured we will want to have a test suite for cvs2svn as well.
> > > > That's where this would be useful.
> > >
> > > Sam, can you describe exactly how parsing CVS/Entries files is useful
> > > in testing cvs2svn? I'm still not seeing it.
> >
> > I sent that before thinking hard enough here. Unless you were
> > dumping lots of internal state from cvs2svn, and using that to test as
> > well (a bad idea, I think), there's nothing that the Entries files
> > tell you that the files themselves don't.
>
> The cvs2svn process is not going to use the cvs cmdline, so we'll never see
> an Entries file.
Right.
> On the other hand, it *will* dump a good amount of state because there are
> repositories out there where the state cannot be in memory. Thus, it will be
> on the disk.
The only way you could use the Entries file would be to dump lots of
state, so you could convert CVS revision numbers to SVN revision
numbers, and then compare the entries files. Like I said, there are
much better ways of testing cvs2svn.
sam th --- sam_at_uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:29 2006