tsait1 / svnx

Automatically exported from code.google.com/p/svnx
0 stars 0 forks source link

Repository button opens repository not for working copy #170

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Add repository (for example, http://svnx.googlecode.com/svn/)
2. Check out working copy (for example, http://svnx.googlecode.com/svn/trunk/)
3. Open working copy window.
4. Push 'Repository' button in toolbar in working copy window.
5. Observe path of opened repository.

What is the expected output? What do you see instead?
Expected repository for working copy, i.e. 
http://svnx.googlecode.com/svn/trunk/. Instead repository 
http://svnx.googlecode.com/svn/ is opened.

What version of the product are you using? On what operating system?
svnX 1.3.3 on Mac OS X 10.6.8, but is reproducible on 10.7.4 too.

Please provide any additional information below.
It is a regression, svnX 1.2.x opened correct repository which corresponded to 
working copy.

Original issue reported on code.google.com by vsap...@gmail.com on 10 Jun 2012 at 1:11

GoogleCodeExporter commented 8 years ago
Unless I’m misunderstanding you - this is by design.
In svnX prior to 1.3 clicking the Repository toolbar item would sometimes open 
another repo window.
In svnX 1.3.x it tries to reuse or open a repo window that best matches the WCs 
URL thus reducing multiple repo windows for different parts of the same repo & 
delays due to re-caching the repo.

Note: A repo window browsing http://svnx.googlecode.com/svn/ can be switched to 
http://svnx.googlecode.com/svn/trunk/ by simply double-clicking ‘trunk’ in 
the repo browser.

Original comment by chris...@gmail.com on 10 Jun 2012 at 5:45

GoogleCodeExporter commented 8 years ago
Before step 4 there are only 3 windows open: 'Repositories', 'Working Copies', 
'svnX' (working copy). So there is no repository window to reuse.

I understand that I can immediately go to necessary repository. But my use case 
is like this: I have working copy '/foo/branches/bar' and I want to open 
repository for this path, but repository '/' is opened instead. It takes a lot 
of time to fetch commit log for '/' and after that I have to navigate manually 
to '/foo/branches/bar'. This is not very convenient. I understand that I can 
add repository pointing directly to '/foo/branches/bar', but duplicating 
working copies and repositories isn't convenient too.

Original comment by vsap...@gmail.com on 10 Jun 2012 at 6:19

GoogleCodeExporter commented 8 years ago
Yes, it can take a while to fetch a repo’s log initially.
However, this should get cached (per Repositories list item) & then only new 
entries require fetching.
[All the more reason to reuse the same repo URLs.]

You are correct that you can add an item in the Repositories list that has the 
full (or partial) path referenced by your WC and that that repo window would be 
used in preference to one with just the root URL of the repo.
[SvnX tries to pick a repo with the longest matching URL to the one used by 
your WC.]
However, duplicating a WC is unnecessary and duplicating a repo is simply a 
matter of option-dragging it in the Repositories list.

So, svnX will cache the logs of repo URLs listed in the Repositories 
list/window.
You can add URLs of repo sub-directories to the Repositories list to give 
customised repo windows.
SvnX with choose the best matching URL to your WC - optimising cached log reuse 
& allowing custom repo windows.
I believe that for all use cases this is better in svnX 1.3.3 than it was in 
1.2.

Original comment by chris...@gmail.com on 10 Jun 2012 at 11:01

GoogleCodeExporter commented 8 years ago
Probably 1.3.3 approach is better than 1.2. But I use the scenario described in 
'Steps to reproduced' pretty often and 1.3.3 disrupted my workflow.

So I think that the issue can be closed as 'Behaves Correctly' or you can leave 
it lying around for a while and see if somebody else expects the same behavior 
as me.

Original comment by vsap...@gmail.com on 12 Jun 2012 at 10:01

GoogleCodeExporter commented 8 years ago

Original comment by chris...@gmail.com on 4 Sep 2012 at 5:41