[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: Hans-Werner Dietz <hans-werner.dietz_at_dbt.de>
Date: 2007-10-16 11:21:36 CEST

Simon Large schrieb:
> On 15/10/2007, Hans-Werner Dietz <hans-werner.dietz@dbt.de> wrote:
>> Simon Large schrieb:

>> 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.

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 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?

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?

> 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.

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

I know and I already put SubWcRev into my build processes, but I am a
little bit tired from discussion with people who don't know and who have
their own build process (but that's my education problem and not yours)

> 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.

Accepted, I also work in this way some times. And you are right: A
breaking change like use the modified icon also for mixed version will
create new discussions and confusion (Especially for the people who
needs education).

>>> 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.
> Simon

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


To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org

Received on Tue Oct 16 11:25:06 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.