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_at_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_at_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
Received on 2011-08-23 18:00:05 CEST