David Bolen wrote:
>Peter Hansen <[EMAIL PROTECTED]> writes: > > > >>Do you know that Subversion has (as I understand it) a fairly >>intelligent binary file comparison routine, and it will (again, as I >>understand it) not transmit the entire contents of the zip file but >>would actually send only the portions that have changed? At least, >>that's if the file isn't compressed in some way that prevents this >>algorithm from working well. (Note to self: check if zip files that >>can be in sys.path can be compressed, and if py2exe compresses them.) >> >> > >Even if the files were compressed, which has a net result similar to >randomizing the contents and will certainly extend the portion that >appears "changed", the worst that would happen is that subversion >(which does use a binary delta algorithm) would end up downloading the >single file portion of the zip file rather than the smaller change >within the file. It should still be efficient. > >But to be honest, for something like the OPs purpose, it's not clear >that an SCM is needed, since all he's trying to accomplish is bring a >remote copy up to date with the central one. For that you could just >publish a location containing the necessary files and have the users >use something like rsync directly (which is just as efficient in terms >of a binary delta) to update their own local version. > >Of course, if the Subversion server is already in place so it's a >convenient server, or if more of the user base already has the client >in place, it should work just about as well. > >-- David > > I've got this working now, and fyi it downloads the entire zip every time. and svn appears to be very slow at it to. -- http://mail.python.org/mailman/listinfo/python-list
