Stefan Küng wrote on 10 Feb 2010 19:20:00:
>
> On 10.02.2010 10:31, Stefan Fuhrmann wrote:
> /> Spam detection software, running on the system
> "ismx03ftc.vodafone.co.nz", has /
> [snip]
>
WTF!? Bare with me, I still have to use Voodoo-phone
for the next two weeks.
>
> 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!).
>
The only way to prevent this, is by not including your
email address into my posts. It seems to be listed on
at least 4 spam lists ...
>
> /> 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?
>
Nothing magical, just cleanup and / or revert (depending
in what kind of havoc has been caused).
>
> ///>> /> - 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).
>
Those aren't typical TSVN users, are they?
>
> /> 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. /
>
The question at hand is quite simple: Given the minimal
UI impact (one new menu item in log dialog), the simple
implementation (core logic is std::lower_bound - a 5-liner)
and the fact that at least some users will benefit;
why wouldn't we want to implement that feature?
>
> ///>> /> - 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.
>
It is meant to be thrown away - as described in the
original feature proposal.
To make it clearer to the user, I modified to proposal
as follows. The prototype get implemented on a branch
and will result in experimental TSVN builds similar to
what we have done with the x64 port in the past.
I'm willing to handle all these experimental builds.
>
> ///>> /> - 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).
>
If they are built through separate project files, just
specify BuildInParallel="true". See also
http://blogs.msdn.com/msbuild/archive/2007/04/26/building-projects-in-parallel.aspx
-- Stefan^2.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447059
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-12 13:50:54 CET