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].