On 16/10/2007, Stefan Küng <tortoisesvn@gmail.com> wrote:
> On 10/16/07, Simon Large <simon.tortoisesvn@googlemail.com> wrote:
> > 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.
>
> Even that won't help you:
>
> modify file1, commit
> modify file2, commit
> modify file3, commit
>
> Even if no one else made a commit, those three files now have three
> different revisions.
> So: how can you tell from CfM or SubWCRev that this is *not* what you
> call a mixed wc?
You can't. That is what I call a mixed revision working copy, and what
SubWCRev calls a mixed rev WC. It can only be fixed by an update.
> Similarly, you can do an 'update to revision' for each of those files,
> and use e.g. r9 (the rev after the file2 commit). Then all files have
> revision 9, but file 3 has modifications in the repository.
Yep. I have already said all these things. It is really an education
problem. The case he is trying to guard against is:
Developer updates to r1000.
Developer makes some changes and commits at r1100
Developer tells customer that r1100 contains the fix.
Wrong! r1100 contains his 1 commit and 99 commits from other developers.
The OP is looking for a way of showing the developer that his WC is
not really r1100, so he needs to do an update.
But you're right, this is such a broken way of working that we should
not be making a workaround like this.
Hans-Werner, you really need to look at working practices. Maybe use a
stable branch for bugfixes and keep trunk for development, or vice
versa. Look at using tags for making releases. Look at generating
post-commit emails so developers can see what else is going into the
repository. And give them some training!
> > > 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.
>
> Yes, only the range of the listed files. But that range doesn't really
> tell you anything.
> It doesn't indicate whether there might be changes in the repository,
> it doesn't indicate whether you should update, it doesn't indicate
> that your working copy might have mixed revision (due to 'update to
> rev' commands).
I disagree. If it covers the entire WC it does tell me whether the WC
reflects a particular revision in the repository, ie it can be
recreated by checking out at that revision.
Simon
--
___
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:29:49 2007