[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-15 14:59:28 CEST

On 15/10/2007, Hans-Werner Dietz <hans-werner.dietz@dbt.de> wrote:
> Simon Large schrieb:
> > On 15/10/2007, Hans-Werner Dietz <hans-werner.dietz@dbt.de> wrote:
> >> I have a feature request. I like to see a different Icon if a version is
> >> "mixed". I think best is a new icon, but also the "modified" Icon is
> >> better than the green "normal" Icon because mixed versions are not
> >> really clean.
> >
> > No, we will not add any more icons:
> > http://tortoisesvn.net/node/3
> I know this and expect that you are angry about new icons. But the users
> has to be notified in some way. Maybe an Icon or something else.

No, not angry, just explaining why we cannot add any more icons.

> But a
> green Icon, which most users understand as "ALL-OK" is definitely not
> the best way for a possible mixed version.

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.

> >> Status 3) A gets 1001 mixed (even if an "update" only pushes the "mixed"
> >> away without getting updates in the source code at the working
> >> copy)
> >> Status 4) B gets 1002 mixed
> >> Status 5) B gets 1002 (without mixed)
> >>
> >> At 3) and 4) SubWcrev gives me the information that I have to make an
> >> Update. So in this case another Icon for the working copy's directory is
> >> better to indicate the mixed-revision situation
> >
> > SubWCRev is not telling you that there is more information in the
> > repository, only that your WC has not been updated to the same
> > revision throughout. At stage 3, if user A updates he will get a
> > normal, unmodified, unmixed working copy. After B commits his changes,
> > SubWCRev will continue to give A the same result. It does not contact
> > the repository.
> >
> I know that at stage 3 User A stays at his revision 1001 and is NOT
> notified, that user B made a new revision. But that is exact what I
> expect and what I DONT want to change. I know that SubWcRev gives the
> same result and it is OK: If somebody checks out this revision for
> debugging an old version of the program he exact gets the same sources
> as the developer has on the working copy.

But how does the developer know what revision he has unless he uses
either SubWCRev or Check for Modifications? If you assume that the
version of your most recent commit is the revision that your WC is at
without updating, you are just plain wrong.

> BUT: At stage 4 it is not so. If somebody later checks out revision 1002
> he get state 5. So if the developer tests and delivers the version at
> state 4 he has no easy optical notification that he does something
> wrong. Of course it is the developers fault not to make an update after
> commit. I know this and I handle it correct. But most people don't, they
> only see green and assumes that everything is ok. And also if they
> enable the SVN columns in the explorer: SVN Revision tells them Revision
> 1002 and no easy hint.

I suggest you change your build process to include using SubWCRev. It
is also a good way of including the revision number into your

But suppose for a minute that we make the folder icon change to the
modified state when there are mixed revisions. Who is going to
persuade the existing users that this is a good feature - that they
will not be able to see the true modified status unless they update?
There are often good reasons for NOT updating all the time, like you
want to keep the rest of the files stable while you work on one
particular file.

> > The only reliable way to check is to use Check for Modifications and
> > use the 'Check repository' button.
> I don't want to check the repository for Modifications online. If a made
> a commit, than unplug the network cable and than call SubWcRev: It
> correctly tolds me that the version number AND that the version is
> possible mixed.

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.


  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 Mon Oct 15 14:59:41 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.