On 12.02.2010 13:50, Stefan Fuhrmann wrote:
> 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.
I thought as much :)
>> 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 ...
Never thought that my answers to this mailing list would get me listed
in in spam lists!?!?
But considering the modifications of that spam-filter to mails I'm not
surprised: the guy(s) who wrote that have no clue what they're doing.
They don't even know that the first thing spammers do is to fake the
from: address. That's why the spam filters that actually work only list
spam *servers*, not addresses.
I wonder how much money they make by having no clue at all...
>> 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?
Actually, yes. Because TSVN is easy to use, those are the majority of
TSVN users.
> 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?
Ok, if you think it's not that much work.
>> 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.
And that's what I really don't like. I don't like TSVN (or its users) to
be used as a guinea pig.
> 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.
You're aware that if you do this on a branch, very, very few people will
use and test it?
>> 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
This won't speed up the build process much: if you check the CPU during
the build you'll notice that most of the time it's not the CPU that's at
the limit but the harddrive. Using a parallel build won't help in such
situations.
Also, msbuild is pretty useless without extensions. And rewriting
everything we've done with NAnt would require a *lot* of extensions and
take a whole lot of work for (IMHO) without gaining much or anything at all.
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=2447162
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-12 20:34:02 CET