On 10.02.2010 10:31, Stefan Fuhrmann wrote:
> Spam detection software, running on the system "ismx03ftc.vodafone.co.nz", has
[snip]
Please, please: check your mailer and deactivate this stupid spam
detector. I've never seen such a stupid one who actually adds its own
spam to a mail. Even the less worse ones only change the subject of a
mail, but never add to the mail itself (and at the top!).
>> 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.
It doesn't work on the tree view, only in the list view. Only Win7
allows shift-clicks on the tree view.
> 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.
How would you fix corrupt wc's?
>> 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)
Ahem: have you asked around not just in your own company? I've seen a
lot of companies who don't even use source control (besides zipping up
the source about once a week or copying their source folders and rename
them with the date).
> 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.
But that means we can throw away the whole thing once it's done in the
svn library. No, wait: we would have to support that code forever to
stay compatible.
>> 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.
The TSVN binaries (the ones done in the .sln) already are compiled in
parallel. As for the libs, I haven't seen that msbuild would parallelize
those (I'm using msbuild in the office for our project).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2446486
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-10 19:20:13 CET