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

would like the ability to break multiple locks in the repo browser

From: Humberto Madeira/Trapsoft Inc <Humberto.Madeira_at_trapezegroup.com>
Date: 2005-11-12 00:21:02 CET

>Stefan Küng:
>Can you please first explain *why* you have to break locks in the
>repository browser? You can break multiple locks from the working copy
>much easier - and there you even might have a reason because you want to
>actually work on those files. But in the repobrowser?

Yes.

The project with the problem is not one I am working on.
I am just an occasional administrator
with my own coding responsibilities on another project.
I would prefer not to have to download that (non-trivially sized) code
needlessly.

After your comment, I went looking for, and now realize that, you can use
the "Check for modifications" dialog with the "show unmodified" flag set
and then press the check repository button to perform this task.

So yes, I did not RTFM (oops, MMC). But going into "TortoiseSVN->Check for
modifications"
to see who else has orphaned locks seems counterintuitive to me.
My first (and I believe more natural) choice is to head for the Repo
browser
and treat it as the repository admin tool.

In any case it takes at least as long if not much more time to collect the
orphaned lock info
by checking out the repository and opening the "Check for modifications"
dialog
as it would have if it had been in the repo browser.
And considering I don't really need the modifications info in the first
place
(it is not my project) I suspect it would be more efficient.

So if the flattened hierarchy view in the "Check for modifications" dialog
had been presented in the repo browser as an alternate way of viewing the
repository,
it would have made more sense to me, it would have taken less time,
and I could have avoided copying the project contents on my hard drive.

>Stefan Küng:
>To find out if a subfolder contains locks, we would have to recursively
>'open' all folders and do an 'svn ls' (svn_client_ls2() resp.).

Yes, but this is no different with the "Check for modifications" dialog.
By forcing a checkout, you are just burying this time as noise in the
overall checkout time.

This is assuming you do not already have it checked out (as in my case).
But even if you do have it checked out, you still have to collect this
information from local files,
and add the more up-to-date info coming out of the server.
(hopefully you can get this up-to-date lock info as a delta based on
revisionID,
or you will have to "svn ls" every folder just the same)

In any case, if the aggregate lock info takes too long to get from the
server,
maybe you could ask the server guys to store and maintain the aggregate
info for you
(similar to how multidimensional database warehouses do it).

Additionally, if you want to present the flattened tree as a list,
then you could also talk to the server guys about getting the info in
cursor form,
and paginate through it.

Or alternatively, you could asynchronously load it in the background
and present the first page, with the rest available incrementally.

In the meantime, you could offer the feature as a button accessed service,
the way you do on the "Check for modifications" dialog,
so it doesn't slow down normal operations.

>open the repository browser, go to
>http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
>Ctrl-Click on the '+' on the left of /trunk. (Or hit Ctrl-F5).

Actually, it came up quite a bit faster than some tree code I've seen.
It could be usable as-is as long as you access it as a special mode and
give a warning.

Regards,
--Bert

--
Received on Sun Nov 13 22:28:15 2005

This is an archived mail posted to the TortoiseSVN Users mailing list.

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