What is meant by "subversion can handle binary files" is not referring
to the work process, but rather how the backend handles it.
AFAIK, In CVS, if you check in a binary file, edit it, then commit it,
that binary file will simply be re-uploaded to the CVS server, with no
diffing done. So if the file is 2MB, then you edit, save, and the file
is now 2.1MB, it will now take up 4.1MB in the repository.
With svn, that same file would now take up ~2.1MB in the repos after the
Andre Pietsch wrote:
>you misunderstood me or, better, I did not express myself accurate enough :)
>Binary file merging is impossible as long as the merge tool does not know about the internal structure of the binary file. This will be always the case.
>What I'm saying is that since this fact IMHO it is not possible to have multiple people working on the same binary file.
>The only consequence is to PREVENT people from doing this. Therefore you need a lock mechnism.
>If a tool like svn claims to handle binary files correctly I assume that this is not limited to a more efficient way of storing it.
>So, if nobody can tell me differently IMHO SubVersion should not claim that it can handle binary files. Being better in one feature but leaving a vital other feature away when compared with CVS does not make it superior but inferior.
>I might be wrong on this, but we are in the unlucky position to have a lot of binary files here and we cannot switch to SubVersion because of the lack of a lock mechanism.
>No problem for me, I can wait for the version when this is supported (I know that is on the todo list), but I do not like the aspect of "false advertising". This is a harsh phrase but what else is it?
>I appreciate your comments, maybe I got something totally wrong here.
>What would the best thing is that the lock feature moves a bit up on the priority list... :)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 4 20:35:13 2004