[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reducing "out-of-date" errors

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-08-03 20:24:24 CEST

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
> and similar cases where you'd expect the Subversion implementation to be
> drop-in substitute for a CVS (or whatever) version.
> May I suggest that it might make sense to keep the implementation of the
> 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
> 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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.