> "D.J. Heap" <djheap@gmail.com> writes:
>
> > Yes, there may be a better way to handle the problem, but I'm not
> > terribly familiar with the working copy and log running code. And
> > that is correct -- this is just attempting to detect the situation
> > where other applications already have files open and locked that we
> > need to update, preventing us from updating them. In the distant
> > past, failed updates like this didn't cause the working copy to end up
> > locked -- but now it does.
Pardon me for butting in -- I don't understand everything being said
here, because I'm not familiar with the code involved, so this may
have already been suggested...
I have a wrapper program that goes through the "svn log -v"
output for any path, between revisions WC+1 and HEAD, and gets the
list of updated sub-paths. It then goes through all these paths
locally, renames them, updates only "unversioned" local files, renames
them back, and then updates the rest. Files that fail to rename are
marked as probably having some local-lock issue, and get skipped at
update. It then updates the parent directories, but only iff those
directories dont have any local-lock issues underneath them. This
prevents the need for cleanup, which takes a really long time on our
systems (NTFS, 16GB repo, ~190K files, ~85K folders). This also
prevents the annoying "unversioned file exists" update issue. This
tool also has a flag where the parent directories are not updated at
all, so the slow directory-walk update pass doesn't take place at all.
This saves us a lot of time.
Anyway, maybe this patch can use a similar trick, to check
local-lock status, and just skip updates on parent directories where
local-lock issues exist, and report the problem to the user. Other
directories and files could be updated normally. This would prevent
the need for cleanup, which is the biggest slow-down issue for us.
Also, files and parent directories that fail to update wouldn't have
their WC version number changed, and thus continue to reflect
recursive version status correctly. Prevention here is probably more
efficient than trying to correct status data afterwards.
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 2 04:28:29 2006