Mark Phippard wrote:
>kfogel@newton.ch.collab.net wrote on 06/22/2005 07:39:41 PM:
>
>
>
>>Why are you having to update the folders?
>>
>>
>
>I would assume it is because the WC is out of date (like when another
>developer committed the last build). These are probably updates to
>existing files. One option would be to come up with a system where they
>only commit new files. That would solve both problems.
>
>
>
Exactly, another developer committed the last build.
>>I think we'd want a --ignore-conflicts option, and/or an
>>"svn:resolution" property that says how to resolve a conflict (values
>>could be 'working', 'new', 'old', etc). Thoughts?
>>
>>
>
>I thought I read recommendations in the past that said you could provide a
>script for diff2/diff3 or something like that, which just says there are
>no conflicts? He would still have to update though.
>
>Jason, did you know Subversion only stores the binary differences? For
>some types of binaries, even if the binary itself is large, this could be
>a small amount of data. Both to send over the wire and store in the
>repository. For other types of files, it winds up being the entire file.
>
>Mark
>
>
>
>
>
Yes, we love the binary differences feature. A lot of our code is in
LabVIEW, where the source is a few hundred binary files. Subversion has
been the best tool we've found for keeping the code controlled, even as
we work in different cities and do a fair amount of travelling too.
Source code updates are generally very fast. But when we create an
installer, the all the source code and the runtime engine are thrown
into some MSI file, and because of the compressed format, the binary
diffing doesn't help at all.
It's not the end of the world to update before we commit, but it is
getting more annoying.
Thanks,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 19:15:55 2005