On 08/23/2011 10:32 AM, Julian Foad wrote: > Mark (or anyone), do you recognize the use case described by Clemens > Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>? > > Use case (2) - Eclipse folder, from issue #3028 > > "For example we have a complete Eclipse instance in our svn > repository and we want to ignore every change in its directory > and below. Because Eclipse more or less at random creates and > deletes file from its own directory we have no way of knowing > which individual files may be change or deleted by starting > Eclipse. To avoid that an update creates files again that were > deleted by running Eclipse the ignore setting I am asking for > should also apply to updates. [...]"
That's quite a pickle. I'm not intending to make holding stuff recursive, because then we'd have to check every commit target up into its ancestors, possibly even checking if the *repos* has a hold set on an ancestor. Ugh. So svn:hold will not support this use case. Maybe they can trick something up using externals, too....... uh........ *drop* (<-- a penny) Come to think of it... we *do* have file externals, too. And, my goodness, it *is* *already* possible to create a global hold on a file using file externals. It is just less convenient: [[[ echo templ > templ echo foo > foo svn add templ foo svn ci -mm svn up svn rm templ svn ci -mm svn up svn ps svn:externals "^/templ@1 templ" . svn ci -mm svn up svn st echo secret >> templ echo mod >> foo svn st svn ci -mm #Sending foo #Sending templ #svn: Commit failed (details follow): #svn: File 'templ' is out of date #svn: File not found: transaction '3-3', path '/templ' ]]] Creating an intended modification of the template would entail resurrecting the templ file somewhere, and then updating the external's peg to that. (could also be in e.g. ^/templates instead of from deleted history). But now, all naive commits are blocked, because the file external is perpetually out-of-date. Users will ask for --exclude <glob> AKA svn:ignore-on-versioned-files AKA svn:hold all over again. BUT, when we simply don't by default let 'commit' "recurse into" file-externals that have a peg revision, well, frankly, there might be no need for svn:hold at all. (Kinda hard to admit that, but there you go) Have I actually leveraged svn:hold out of svn with this? :) I still think svn:hold is a better, less confusing, more convenient solution. What do you think, tip towards being downwright conservative or being convenient? Downsides to using file externals as a means to hold: - There is no convenient way to hold locally-only, or the problem perpetuates, because now you want only one svn:externals entry (and possibly a local-delete) to be kept out of all your commits -- an insane minefield. Better for local-only hold: add an --exclude <glob> option to commit, BUT it would have to be set explicitly on every commit in all the right WCs. Per-user ~/subversion/config for this may not be specific enough to conveniently affect only the right paths. - It is harder to create an intended modification on the template. (resurrect&mod the file, then update the externals definition. But may also be done on a dedicated branch like ^/templates) - It may be confusing to average users. Well, only so much. How does the merge situation resolve when using file externals? [I'll run trials and be back with another mail on merge] Well, at least now I'm definitely against svn:hold acting recursively on dirs. Users that want this can use above approach with dir externals (showcased below), where commits don't even recurse into the external, so it is fairly convenient. The only downside is that only a global setup for this is really useful (or have to keep svn:externals propset out of commit). [[[ mkdir tdir echo templ > tdir/templ echo foo > foo svn add tdir foo svn ci -mm svn up svn rm tdir svn ci -mm svn up svn ps svn:externals "^/tdir@1 tdir" . svn ci -mm svn up svn st echo secret >> tdir/templ echo mod >> foo svn st svn ci -mm #Sending foo #Transmitting file data . #Committed revision 4. # yay! 'templ' was not sent! ]]] ~Neels
signature.asc
Description: OpenPGP digital signature
