On Tuesday, August 12, 2014 09:43:39 AM Branko Čibej wrote: > On 12.08.2014 09:26, Alexey Neyman wrote: > > On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote: > > > So why do you need the last-changed revision of the project directory > > > stored in the header file? Are you distributing sources directly from > > > the repository, or are you using that number to identify builds? In > > > either case, there are better ways to do that. > > > > Sometimes, yes. Not directly from a repository but engineers sometimes > > release semi-official builds to customers. > > > > I understand that is less than ideal way (not dealing with > > mixed-revision WCs, etc.). So, I am curious what are those better ways > > you mention? > > I'm sort of assuming a defined build (or packaging) workflow. If you > have engineers mailing binaries from their mixed-revision development > working copies to customers, all bets are off, since they might have > locally modified your version property. > > One solution is to run "svnversion" as part of the package/build and > include the result in the build artefacts. Can't go into any more detail > than that, since I have no ides what your build system looks like. This > won't always perfectly identify the configuration you're building, but > at least it will give some indication of the state of the working copy, > and whether (oh horror) it includes local modifications.
1. svnversion reports the revision of the check-out, not the revision of the last modification. 2. svnversion does not provide the $Date$ information. 3. svnversion won't report anything on 'svn export'-ed sources. All that would be handled if there were a way to modify a transaction being committed :) > > - Second, some of the MIME types are text even though the MIME type > > does not start with 'text/*'. "image/svg", "application/x-sh" and > > "application/xml" are a few most obvious examples that come to mind. I > > don't know how to come up with an exhaustive list of such > > "text-despite-MIME-type" types. > > Heh, tell me about it. Subversion has the same problem, and we still > haven't found a satisfactory solution for it. Well, if Subversion set an svn:binary to true/false just to report the heuristics, in addition to svn:mime-type, that would've helped somewhat. But Subversion heuristics only runs on newly added files. > So you really only have to add this property on added files, right? Have > you considered using auto-props? They don't currently give you exactly > the knob you need, because we don't have an auto-prop setting for "all > binary" or "all text" files, but maybe that could solve your problem. No, it is also set on existing files as they're modified. > Especially now that, with 1.8, you can define auto-prop settings in the > repository and no longer need local configuration on every client. > (Caveat: you do need 1.8 clients.) Now you tell me about that. I am still trying to weed out 1.6 clients (which break horribly by nested 'svn mv')- since CentOS does not update the base version of the packages during the release lifetime, CentOS 6.x is stuck with Subversion 1.6. Thanks to WanDisco for providing the CentOS RPMs for Subversion 1.7/1.8 :) It would be nice if there were a 'start-access' script that is run on any access to the repository - that can be used to block such older clients from even accessing the repository. Speaking of 'wish' items: - How hard would be to implement client-side hooks? I know TortoiseSVN has them, but they're local - and to be really useful, they need to be propagated from the repository. And it would be nice to have them supported by the default commandline client. If they were supported, the tasks like the ones described above could be relegated to the client side, and the server-side hooks could then just reject the commit if the client failed to run the script. - How hard would be to allow modifications to a transaction by pre-commit? If it is just the issue of client-side caches going stale - can a "shadow transaction" be created that records all the modifications by the pre-commit script and then sends it back to the client to apply to the WC? Regards, Alexey.
