[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [TSVN] Politics of SVN[Scanned]

From: JS.staff <jsparrow_at_ecclescollege.ac.uk>
Date: 2004-08-13 23:03:31 CEST

That's really sad, they need their butts kicking!!! All the more reason to mobilize a Windows user action group!
 
FORK FORK FORK... grin.
 
(or should I say /branch /branch /branch???)
 
(Direct action?? We can commit junk to their tree. That will speed up the implementation of the 'svn obliterate' command, LOL)
 
But seriously, I will start reading the Subversion lists. They obviously need some more Windows input. Anyone would think we were the 2% of the OS market... :0
 
About the .svn / _svn thing: point taken (although since every Windows developer in the known universe (almost!) uses VS, I think its weirdness should be taken as 'standard'). M$ do no wrong, of course ;)
 
Would there be a performance penalty in having all these system folder in one central place, instead of in the working folders? Like c:\svn or something?? Is it logically sensible to have them embedded in the file system instead of in a nice db somewhere?? (yeah, that's a bit radical I know, and way outside the scope of TSVN).
 
Whatever, I find it hard to totally blame M$ for this, when the guys at Subversion are asking Frontpage extensions (on a potentially live website) to conform to Unix naming protocols for hidden folders. It's kinda not suprising it doesn't work!! Anyone would think they didn't like Windows ;)
 
Sleep well Stefan n all,
 
John
 

        -----Original Message-----
        From: SteveKing [mailto:steveking@gmx.ch]
        Sent: Fri 13/08/2004 21:28
        To: dev@tortoisesvn.tigris.org
        Cc:
        Subject: Re: [TSVN] Politics of SVN[Scanned]
        
        

        JS.staff wrote:
        
> I don't have any gripes really (being new), but have you thought
> about posting a list of issues *you* think are a problem with SVN, so
> that the rest of the TSVN users group can hassle the SVN people
> about??
        
        As it's Subversion policy (and TSVN's too): everything has to be
        discussed first on the mailing list. Issues are only filed if there's a
        consensus about a problem/bug/enhancement/...
        So I do report the problems on the Subversion mailing list, and if
        there's a consensus then I file an issue. There are some issues in the
        subversion issue tracker which I started.
        The problem is: even if there are issues filed, that doesn't mean that
        they get fixed/done.
        Sure, you could say that if it bothers me that much I could write a
        patch to solve the issue. Been there, done that.
        Example? Here you go:
        Since TSVN links against the Subversion library twice (one
        TortoiseProc.exe and one is TortoiseSVN.dll) it would save a lot of disk
        space if Subversion would compile in a dll and not just link statically.
        So I suggested that on the mailing list (about 1.5 years ago). Consensus
        was there, but no one there seemed to have the time (or the motivation)
        to do it. So I wrote a patch for it. I did it the same way the apr
        library does it - I thought since Subversion uses apr that this would be
        ok. Wrong! My patch got rejected. They'd rather have some script which
        would automatically generate a def file for the dll. I told them that I
        don't know perl or python so I couldn't write that script.
        So, instead of using a patch which worked (tested myself with TSVN),
        they rather wait for a script which most likely will never be done. At
        least it hasn't been done yet.
        
        I did some other patches which got rejected too. So I stopped working on
        the Subversion library completely. I'd rather work on TSVN where my work
        is put to good use than to work on Subversion for nothing.
        
        So if I think something should be done in Subversion, I write a mail to
        the dev list there, try to explain why I need that fixed/done. But
        nothing more. If they don't react or simply reject the idea, I stop
        discussing - I've got better things to do than wasting my time. If then
        later the problem I mentioned comes up and bothers lots of TSVN users, I
        have to tell them to complain on the Subversion mailing list, hoping
        that many people complaining will convince them to do something about it.
        
        And in the case of the apr-iconv library, well, if they don't do
        something, I did. apr-iconv is now patched for TSVN. I haven't told them
        that I patched it - maybe I should because I know that will get them
        angry ;)
        
> My only issue is with the .svn / _svn thing (yeah, I know, it's all
> been discussed before my time! LOL). But I'm gonna say my piece
> anyway :)
>
> It's not your problem Stefan. In my opinion the standard folder name
> should be '_svn' in Windows on *all* clients, and '.svn' on Unix.
>
> There's a good reason for having a leading period on a Unix file
> system, it means something special. But that isn't the case on
> Windows. You could call it 'SecretHiddenSubversionFolder' for all
> Windows would care!
        
        The problem is: Windows can handle the .svn directories _very_ well.
        Only the VS.NET web projects have a problem with them. And who's to say
        that if you change the name to _svn that no other app will have a
        problem with those?
        
        Stefan
        
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
        For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
        
        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org

Received on Sat Aug 14 12:29:51 2004

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.