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

Re: mime-types

From: Hari Kodungallur <hkodungallur_at_gmail.com>
Date: 2005-02-07 21:07:48 CET

Sorry.. wrong list. Should have sent to cvs2svn list.
Please ignore.


On Mon, 7 Feb 2005 11:33:07 -0800, Hari Kodungallur
<hkodungallur@gmail.com> wrote:
> Forwarding to the group. (Hit the Reply instead of Reply All which
> sent email only to Karl)
> ---------- Forwarded message ----------
> On Sun, 06 Feb 2005 19:42:30 -0800 (PST), kfogel@collab.net
> <kfogel@collab.net> wrote:
> > I think it would be better for one to write a script to do that check
> > on the CVS repository, and set -kb. cvs2svn's job is to accurately
> > convert the data it finds.
> >
> In principle, I agree with you that its always better to fix the files
> in the CVS.
> Having said that, my guess is that this happens too often in CVS (that
> there are binary files that are not -kb). I can not see any reason why
> anyone would save a text file with a jar or zip extension. And so, my
> suggestion to have a fix in the cvs2svn was aimed only at ease of use
> and to save some time. I bet that there will be cases where the CVS
> repository will be converted only to find that some binaries were
> courrpted. The result being that the conversion has to take place all
> over again.
> If there was an option for cvs2svn to pass a list of files to be
> considered as binary files, then potentially a large number of users
> will save themselves time writing scripts to convert their CVS binary
> files to have -kb switch. And, in some cases, also save time by not
> having to convert the respository twice (because they noticed the
> corrupted files only after cvs2svn conversion).
> My 2c.
> Thanks!
> -Hari

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 7 21:13:20 2005

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

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