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

Re: cvs2svn: log conversion

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-02-27 02:42:04 CET

On Wed, 2004-02-25 at 13:20, Jack Repenning wrote:
> Your idea here seems to be "import it so (as much as possible) it looks
> like it had always been maintained in SVN."
>
> My idea here is "import it so (as much as possible) it looks like it
> always did, which, yes, includes a disreputable period within that
> blasphemous CVS."
>
> I think I said that already. I can't see, in your response, that the
> point was received. Maybe I'm clearer this time?

Your point is clearer, but I don't see the argument along that axis. I
think the simplest and most accurate way for SVN to model CVS's
pathnames-which-contain-file data is to create one totally independent
file for each contiguous period where the pathname had data. To do
something more complicated is to make a guess as to the origin of the
resurrected data. If the guess happens to be right, everyone is happy.
If the guess happens to be wrong, now the repository is more complicated
and less accurate. (Put more clearly: since we have to guess, it's best
to make a simple guess.)

Separately, I think your argument falls down because (I assert) it's not
common for CVS repositories to contain resurrected pathnames. If this
were a common case, I could see wanting to handle it in a way which
eases the transition from CVS, but when you're talking about the most
cornery of corner cases, I think it's best to accept the argument from
simplicity and correctness, rather than the empirical argument.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 27 02:41:41 2004

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.