Re: Patch for identify binary file attributes from CVSNT

Michael Haggerty <[email protected]> Thu, 18 Apr 2013 23:53:43 +0200
Newsgroups gmane.comp.version-control.subversion.cvs2svn.devel
Message-ID <[email protected]>
On 04/18/2013 04:11 PM, Filipe Borges wrote:
> I am in the middle of the migrating process of our corporative CVSNT
> repositories to SVN and found that cvs2svn can=E2=80=99t identify binary =
files
> in CVSNT.
>=20
> After a little research I could solve this adding some lines to the
> python parser.
>=20
> Please find the patch attached.

Thanks for your contribution!

As far as I understand, CVSNT stores the binary/non-binary attribute for
each file revision (as opposed to CVS, which records it once for the
whole history of the file).  So, strictly speaking, it is not correct to
take the kopt recorded for one file revision and apply it to all file
revisions, which is what you are doing.  However, cvs2svn only records
one file expansion mode for each file, so it would be a lot of work to
handle this correctly.

Now in practice it might be that most files keep the same expansion
option across their lifetime, in which case picking any one from its
history is probably not so bad.  Is this your working assumption?

What if the expansion option varies over time?  Even assuming that we
don't want to invest the time to implement the correct
(revision-by-revision) solution, it might be possible to do better than
your patch with little work:

* Your patch essentially uses the *last* kopt listed in the *,v file for
the whole file history.  It might be better to use the *first* one,
which is more likely to be a recent revision.  (This is under the
assumption that the file mode was wrong during part of its history, it
was more likely to be corrected over time than to be changed from
correct to incorrect.)  Or unconditionally to use the kopt from the HEAD
revision.

* Alternatively, we could decide which kopts are "safer", and always use
the "safest" kopt that was found in the file.  For example, treating a
text file as binary is less likely to be catastrophic than vice versa.

I'm not saying that I won't accept your patch as it is; I am just hoping
to get your thoughts on these issues before committing.

Thanks,
Michael

--=20
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=3D1667&dsMessageId=3D=
3053681

To unsubscribe from this discussion, e-mail: [[email protected]=
s.org].