On Tue, Mar 24, 2009 at 2:51 PM, Mark Booth <li...@anang.com> wrote: > In message <3f40cf550903161139m1cfd4705yf8f99ab34a395...@mail.gmail.com> > on Mon, 16 Mar 2009, Steve Borho <st...@borho.org> writes >>> In talking this over with an affected co-worker, we both agreed that >>>while this super-cache of path names might be useful in some limited >>>circumstances (which we have not experienced), it has been actually >>>harmful in several circumstances (that we have actually experienced). >>> >>> I was going to open a bug on this, but thought I should ask about it >>>being "desired" behaviour (versus just being the way things are by >>>historical accident/guess-at-what-might-be-useful). >> >>I can see your point. The total URL history would probably be more >>useful in, say, the clone tool than here. > > I'd tend to agree. More useful than a repository cache in the clone tool > would be it filling the source repository with the current repo, if you > select clone from a right click in explorer within an existing repo. It > must already knows whether you're in a repo or not because it changes > the context menu, so it shouldn't be too difficult to default to the > current repo. > >>So do we throw away the >>total URL history, or does it make sense to further differentiate? >>Would you rather see: >> >>Three-tier drop-down with repo aliases | repo history | all history >> >> - or just - >> >>Two-tier drop-down with repo aliases | repo history > > Either of those would certainly be useful. > > The workflow we are using makes good use of the way Hg works, but some > of the practical implementation of it could be smoother. In particular, > the problem described above makes synchronising on our test machine more > difficult than I'd like. We frequently sync it via usb sticks when a > network connection isn't available and different developers have > different directory structures on their usb sticks not to mention the > fact that Windows tends to change the drive letters around over time. > > Because of this the list is getting cluttered up with obsolete repo > locations and it's usually easier to browse for it afresh than find it > in the list. As such, the proposal above would make things much easier. > In the meantime though, is there any way to prune this repo location > cache?
Only by deleting synch* in your %APPDATA%\TortoiseHg dir > >>PS: Feel free to file a bug for it > > I too feel uncomfortable filing bug reports for feature requests, I > figure if I want new features I should bloody well download the source > and implement them myself. *8') Both are welcome. I appreciate feedback on the order in which to address annoyances. I'm making steady progress on these things. But a helping hand would be much appreciated. -- Steve ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tortoisehg-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
