On Fri, Aug 1, 2008 at 3:11 PM, Alexander Litvinov <litvinov2004@xxxxxxxxx> wrote: >> To being able to synchronize efficiently in both ways, you need to store >> files exactly as they were received from SVN then there will be no >> problem with applying binary delta patch. All CRLF conversion should be >> done on checkout and checkin from/to Git repository. > > Sorry I have lost the mind flow here. > > 1. We 'fetch' files from svn as is. Yes, we know that svn use delta to rebuild > original file. > 2. We commit file to git. Right here we use git-hash-object. As I understand > we _have_ to do convertion CRLF->LF here. No, you should do any conversion here. There are two reasons for that: 1. If you do then you will not be able to apply binary patches later. 2. You do not really need it if the SVN repository has correct eol settings, because all files that have svn:eol-style set to either 'native' or 'LF' will have LF. Those that do not have svn:eol-style or have it to another value should not be subject to CRLF conversion at all. So, I believe all files received from SVN should be stored as is. Import is not about creating new commits, it is about getting history from another repository as it is. > 3. In some days we will checkout file from git and wil do LF->CRLF convertion. It is done only for files that do not have CRLF already. > > I thought this is a right workflow. > - We could store original file too at step 2 somwhow to be able to use delta > at step 1. > - We can't skip convertion at step 2. Overwise git will store files with CRLF. It is okay for Git to store CRLF, because you want to treat them as binary files. If you want them being treated as text, you should change svn:eol-style to 'native' for those files in SVN and then new versions of these files will have the right ending. It is how SVN client works. The only problem is how to synchronize the SVN view which files are binary and which are text and what Git thinks about them. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
