On Apr 27, 2010, at 03:57, Paul Breen wrote: > On Mon, 4/26/10, Ryan Schmidt wrote: >> Changed since when? > Changed since the last deployment. The routine would send the file > sizes of the files on the deployed computer to the repository server, > and if the file sizes differed from the file sizes of the given revision > (the current revision by default), the server would send the updated > file to the deployed computer.
Ah, ok, so unlike with a regular export, the proposed "svn export --skipfilesmatchingsize" would operate on an existing directory. It would be like a more-efficient version of "svn export --force", then. The danger of missing a file that needed to be updated, because the old and new filesizes were the same, seems like a concern that would keep the developers from accepting this proposal. Even if your client can guarantee that her files will always differ in filesize, that's not a statement that can be made about all users everywhere, and even if the option is named "skipfilesmatchingsize", some users may come to know the option as "export faster" and not think about what the option name means (or might not be native English speakers), might therefore use the option in cases where filesizes were the same, might therefore not receive updates to some files that did differ, and might experience problems as a result and/or complain here. If checksums were sent, instead of sizes, that should alleviate that concern. In that case one might even argue for naming the option "svn export --update". The developers might still reject this feature on the grounds that it essentially duplicates the functionality of "svn update". >> I think >> you'll be better off using existing solutions to this >> problem, such as rsync from a local svn export to your >> remote deployment, or even simply making your remote >> deployment a working copy and using svn update there. > My client is aware of rsync utility, but would prefer to use svn. I'll > have to correspond with her to find out why she doesn't want to use > rsync. As far as making the remote deployment a working folder and > using svn update, she doesn't want to have the clutter of the hidden > .svn folders on the deployed computers. > > For anyone who's interested, the details of the project I'm working on > can be found at > > www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1395905 > > Here my client gives the use cases for the feature she's looking for. > I'll speak with her about the suggestions I got here and relay her > responses on this mailing list. It seems to me that before a bid request for a coder is advertised, the proposed changes should have already been accepted by the developers. But perhaps the process of getting the idea approved by the developers is part of what your client is paying you for. Note that I am not a Subversion developer, so it's not me you ultimately have to convince, but getting a bunch of Subversion users to agree that the idea is a good one is a good first step before approaching the developer list. If part of your client's concern about using a working copy is the proliferation of .svn directories, she should know that Subversion 1.7 will feature a redesigned working copy model which will consolidate the .svn directories into a single location at the root of the working copy. Perhaps this will already help.
