> There, done. Any holes?
I probably should not wade into this discussion as it seems like
asking any questions gets interpreted as not wanting to see the
feature added. I use OSX (not these features in general) and would
like to see it better supported so that there are no barriers to
adoption.
That being said, I do not see where any of the proposed solutions
really talks about how Subversion actually works and how it would need
to be modified.
Basically, you are talking about the format of the file stored in
Subversion repository and the format of the file in the WC not being
the same. Given that, how would you solve the following?
* client and server communicate with binary deltas. This means that
the client will have to convert local file to repository
representation to exchange deltas. Say there are local changes to a
file, and you are updating from server. The local version has to be
encoded, receive and apply the deltas, and then be decoded again. Can
this be done reliably? How would/could conflicts be handled?
* client uses a heuristic to determine if file is changed locally. In
this case, to check if a file is modified it would have to be encoded,
and then if the size is not different, a byte by byte compare would
have to be performed. This will be very slow. Let's assume it is
worth it, is the process reliable? Does encoding/decoding the same
file always give the exact same results? I am sure the important
parts of a file are always exactly the same but is the actual binary
encoded file always exactly the same? If not, you are going to get a
lot of false positives from svn status, which means those changes will
be committed.
* an alternative to previous, is that perhaps the decoded version of
the file is stored in the WC to make these comparisons faster. But
then SVN needs to be enhanced to compare resource forks too. It also
pushes the complications back to the process that talks to the server
as now an extra encoding step has to happen.
Are all of these problems solvable? Most likely ... there are a lot
of smart people around. I do not think the solution is nearly as easy
as it is being portrayed.
I do not think there is any reason to respond to this email point by
point. I am not a core SVN coder, I will not be making these changes.
I think you should just take these things into consideration in the
proposal and try to address them so we can keep the proposal moving
forward. Or perhaps step back and think of a different approach that
makes these things less of an issue.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 17:08:37 2007