news <news@sea.gmane.org> wrote on 08/02/2006 01:33:38 AM:
> Daniel Rall <dlr <at> collab.net> writes:
>
> > You underestimate how often this situation arises in simpler
> > Subversion deployment scenarios.
> >
> > I'm not saying "do it", just pointing out that in my experience, this
> > is not an uncommon situation or use case.
>
> The thread started out talking about this issue in the context of IDE
plugins
> and similar cases where you'd expect the Subversion implementation to be
a
> drop-in substitute for a CVS (or whatever) version.
>
> May I suggest that it might make sense to keep the implementation of the
"svn"
> client as it is now, but for the implementors of Subclipse and so on to
> automatically check after committing if an "update" would change any
files, and
> if not, execute it? This seems like a nice high-level heuristic, not
> necessarily a core feature. Folks who like this behavior at the command
line
> could perhaps use a wrapper there, even.
I meant to reply to this and forgot.
If it comes to it, we could do something like that, but I was not
suggesting that a real "update" be done. On some of these hosted
repositories that could be 10+ seconds to do nothing. In some cases, we
might have to do 10 or more update calls to update each folder
non-recursively. I was suggesting Commit do a tweak to the entries file
as it was updating it for the file.
I think a non-hackish solution like Max proposed would be the best way to
do this.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 20:32:43 2006