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

Re: Feature Request: Indicator for Mixed Versions.

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: 2007-10-16 12:08:54 CEST

On 16/10/2007, Stefan Küng <tortoisesvn@gmail.com> wrote:
> On 10/16/07, Hans-Werner Dietz <hans-werner.dietz@dbt.de> wrote:
> > > The green icon simply means there are no uncommitted changes. It does
> > > not mean that every file is updated to the same revision, and it does
> > > not mean there are no further changes in the repository. These are
> > > common misconceptions, but we can't change the behaviour to suit
> > > everyone's idea of how *they* think it works.
> > >
> > >>>> The reason is that there are many developers who think that the green
> > >>>> "normal" Icon from TSVN means that their actual working copy is clean
> > >>>> and that they can very easily reproduce all green directories from the
> > >
> > > That is surely an education problem, not a tool problem.
> > >
> >
> > Yes, I agree 100% that it is mainly an education problem. My point is:
> > education is much easier, if a tool like TSVN gives an "every time
> > available" hint that there is something to take care.
> But that would only be possible by constantly polling the server.

He is only talking about mixed update revisions within the WC, not
repository changes. SubWCRev will already do what he is looking for,
but he wants a context menu solution. I think that solution is CfM.

> > But can you agree that an easy optical hint (which cannot be overlooked)
> > which covers the difference between mixed and non-mixed working copy
> > directories would be useful and nice?
> Useful, maybe. Nice? Not really.
> > And can you agree that an implementation is possible from the SUBVERSION
> > POINT OF VIEW, even if an additional Icon is not possible FROM THE
> > EXPLROER POINT OF VIEW because you get limitations and problems by
> > Microsoft's explorer interface?
> You're missing something here.
> It is not possible to know whether a working copy has mixed revisions or not.
> Not. possible. at. all.
> > >>> The only reliable way to check is to use Check for Modifications and
> > >>> use the 'Check repository' button.
> Not really. That will only tell you that a file/folder has a newer
> version in the repository. But that doesn't tell you whether it's
> because you have a mixed wc or because someone else made a commit.
> > > The CfM dialog will also show whether you have mixed revisions
> > > locally, even if you don't contact the repository. I guess we could
> > > put a clearer message there about mixed revisions, but you would still
> > > have to educate developers to actually look at it.
> No. The CfM dialog will only indicate whether you have a nested
> layout. But mixed wc are not shown/indicated.

We're talking mixed revisions here, not mixed URLs or switches. I
think CfM shows the minimum and maximum update revision range covered
by the WC. No wait, it does in 1.4.x but I think in 1.5.0 it is
changed so that the display only shows the range of the files listed.

> > Can you make the info available on right mouse click via the property
> > item and add something to the subversion property-page like the attached
> > picture?
> No, because there is no way to know whether a wc has mixed revisions or not.

I would say yes, but not in the property page because that would mean
doing a WC crawl which would in turn mean a delay before showing that
dialog. CfM seems the right place to show this as it is already
crawling the WC, and it is less mouse clicks away.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Oct 16 12:09:01 2007

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

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