Spam detection software, running on the system "ismx03ftc.vodafone.co.nz", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
root_at_ismx03ftc.vodafone.co.nz for details.
Content preview: Stefan Küng <tortoisesvn_at_gmail.com
<mailto:tortoisesvn_at_gmail.com?Subject=Re:%20Brain%20dump:%20possible%201.7%20work%20packages>>
wrote on 09 Feb 2010 19:09:34: > > On 09.02.2010 11:51, Stefan
Fuhrmann wrote: > /////> New features: / > /> / > ///> - extend
cleanup command to remove various files. / > />
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature / >
/> Proposals/Cleanup.txt / > /> Small improvement. Any volunteers? / >
> We already have the "Delete unversioned items" command >
(shift-right-click to see it). This brings up a dialog showing all >
unversioned and ignored files/folders to select for deletion. > Just
discovered that it doesn't work on my XP laptop (unless
AlwaysExtendedMenu is set). CMF_EXTENDEDVERBS doesn't seem to get set
by holding the shift key. [...]
Content analysis details: (7.1 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-3.3 ALL_TRUSTED Did not pass through any untrusted hosts
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.4636]
2.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
[URIs: tortoisesvn_at_gmail.com]
0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
[URIs: tortoisesvn_at_gmail.com]
1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: tortoisesvn_at_gmail.com]
3.2 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
[URIs: tortoisesvn_at_gmail.com]
4.3 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
[URIs: tortoisesvn_at_gmail.com]
-1.0 AWL AWL: From: address is in the auto white-list
Received: from unknown (HELO ?121.90.196.108?) (121.90.196.108)
by ismx03ftc.vodafone.co.nz with SMTP; 10 Feb 2010 09:31:22 -0000
Message-ID: <4B727CE5.6080606_at_alice-dsl.de>
Date: Wed, 10 Feb 2010 10:31:17 +0100
From: Stefan Fuhrman <stefanfuhrmann_at_alice-dsl.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev_at_tortoisesvn.tigris.org
Subject: Re: Brain dump: possible 1.7 work packages
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Stefan Küng <tortoisesvn_at_gmail.com
<mailto:tortoisesvn_at_gmail.com?Subject=Re:%20Brain%20dump:%20possible%201.7%20work%20packages>>
wrote on 09 Feb 2010 19:09:34:
>
> On 09.02.2010 11:51, Stefan Fuhrmann wrote:
> /////> New features: /
> /> /
> ///> - extend cleanup command to remove various files. /
> /> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature /
> /> Proposals/Cleanup.txt /
> /> Small improvement. Any volunteers? /
>
> We already have the "Delete unversioned items" command
> (shift-right-click to see it). This brings up a dialog showing all
> unversioned and ignored files/folders to select for deletion.
>
Just discovered that it doesn't work on my XP laptop (unless
AlwaysExtendedMenu is set). CMF_EXTENDEDVERBS
doesn't seem to get set by holding the shift key.
The dialog that comes up already does most of what
I wanted in the extended cleanup command. However,
it does not revert changes nor repair the working copy.
My use-case is as follows: Someone or something messed
with the working copy. The user wants to get rid of the mess.
This could be: extra files, modified files or corrupted w/cs.
> What would the "Delete other files and folders" do exactly? What 'other'
> files/folders?
>
In the "Delete unversioned items" dialog they are listed
as "unversioned" as opposed to "ignored". Since both
are technically "non-versioned", I chose the terms
"ignored" and "other".
>
> /> - bisect /
> /> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature /
> /> Proposals/Bisect.txt /
> /> Small improvement. Any volunteers? /
>
> Even with your detailed description, I simply can't see any benefit of
> implementing this in TSVN at all.
>
I need to do the bisection thing every couple of weeks:
As soon as the contributions to a project or module don't
come from yourself, it can be hard to "guess" what change
causes a certain change in behavior (e.g. unexpected side-
effects).
> Let's face it: 90% of all users don't even have an automated build
> script for their source. Those who have, have a script that doesn't
> return TRUE/FALSE for another app to catch.
>
Almost 100% of professional programmers do have automatic /
scripted build. If the project is simple, no script might exist (yet)
but building the a single solution file (or respective IDE equivalent)
is a 1-liner.
The "true/false" return value is for proper test scripts. Plain build
errors would certainly not be fixed using bisection as the offending
part can be spotted much easier.
>
> That might leave ~3% who have such a script to be used. But that's a
> build script - most of the time you want to find an offending revision
> that breaks a feature, not one that breaks a build. And that reduces the
> people who can use this feature even further.
> All others will still have to do everything manually - a dialog which
> stays open and updates to other testing revisions won't help here much
> (if at all).
>
I fully agree that ad-hoc scripting (e.g. bug reproduction scripts)
is quite uncommon under Windows. What I am trying to accomplish,
however, is a greatly simplified / more robust workflow.
Standard workflow an iteration:
(1) manually track test results, pick next revision to test
(2) delete old working copy (or cleanup existing one)
(3) c/o new working copy (or update to revision)
(4) run build
(5) test
That is quite a lot of interaction every couple of minutes as each
step takes a while and it requires close attention not to make
expensive mistakes.
With built-in bisection support, the workflow would be
(1) waiting for the prompt (notification sound) while
TSVN runs steps (1) through (4) automatically
(2) test
(3) tell TSVN the results
(I have to adapt the feature description to allow for manual
input even if a command line is supplied.)
The new workflow is clearly less error-prone. Also, it is
faster while interrupting the user less frequently.
> Does this really justify this much code for something that won't get
> used a lot and therefore also won't get tested enough?
>
The program logic required is very simple. So, not much
code to maintain and eventual errors should be easy to fix.
> /> - experimental patch recorder /
> /> (a simple implementation for "offline / pre-recorded commits") /
> /> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature /
> /> Proposals/PatchRecorder.txt /
> /> Already working on this. /
>
> Wouldn't it be better to implement this in the svn library? I'm sure
> you'll get commit access if you send your specs to the svn dev list.
>
IMHO, there are some good reasons to first pilot the
*use-case* in some client. But I will make a separate
post on that.
> I'll write up some specs for these soon.
>
> /> Odd jobs: /
> /> /
> /> - finish LogCache documentation /
> /> - switch to VS2010 /
>
> VS2010RC is up on MSDN....
>
Let's hope compilation works now.
>
> /> - fully or partly switch to msbuild to speed up build times /
>
> Why do you think switching from Nant to msbuild will speed up the build
> times?
>
It can be parallelized. Even the binary builds (SVN libs & friends)
can be parallelized. Thus, not only releases & nightly builds become
faster but development gets a boost, too. Nothing extremely important
but certainly nice to have and something I like to toy around with.
-- Stefan^2
Received on 2010-02-10 10:31:42 CET