hey, if you cut through the whining there's actually a couple of good
ideas in here!
i especially like the concept of compressing the .svn directory; that
should be easy to implement and solve many things right there.
-alvin
nick vajberg wrote:
> I sent the mail below before, but it didn't get
> through, so i'll try again.
> -------------------------------------------------
>
> I'm getting more and more annoyed having the
> .svn maintainance directories around. I know this has
> been discussed back and forth before, but I still feel
> I have to "file a complaint"...
>
> This is why:
>
> 1. We currently have to use a special build of the
> TortoiseSVN because we use VS.NET. That build use _svn
> rather than .svn. Big problem: we still have to use
> the svn command line client for advanced stuff -
> meaning we have to rename directories when switching
> between clients (ouch!) Also, VS.NET is not the only
> ill-written Windows application having problems with
> this.
>
> 2. It consumes a lot of disk space having that many
> files and directories. The file overhead in NTFS is
> huge. Makes our file/directory maintenance tools run
> slower (e.g. we have a daily disk-to-NAS backup - and
> boy, is it slow)
>
> 3. It makes two of our IDE's grumpy. The .svn shows up
> in the file listings. We have turned on the "hidden"
> flag, but RealJ still sees them (why ?!) Also, the
> Java "package-view" crashes in JBuilder. IntelliJ can
> filter them nicely, though. Any experiences with
> Netbeans/Eclipse, anyone?
>
> 4. Our homegrown ANT JavaDoc processor fails; I guess
> because it expects source directories to contain only
> directories containing java files. I haven't found a
> workaround other than doing a clean SVN export :-( We
> can fix it, but why should a tool expect junk to
> suddently appear in the source directories? Our UML
> reengineering tools fails for the same reason (which
> is NOT developed by us)
>
> 5. ...
> 6. It slows down TortoiseSVN because it uses icon
> overlays and has to scan more files. Not your problem,
> really, but still...
>
> 7. It makes grep'ing, etc harder; ~50% redundant hits
> (we can filter in Windows Grep but it's very
> inconvenient in general). Windows' search function
> also returns redundant hits. In general, it makes it
> inconvenient to use a lot of "sharp" tools; often one
> or more extra switches is needed or we need to do a
> clean export.
>
> I always hated CVS for doing things this way.
>
> Suggestion for SVN 1.x: Move the maintenance stuff in
> a separate place and store it in a compact form -
> perhaps even compressed. Having text/xml files was
> probably nice while developing SVN (easy debugging),
> but I see no reason why the WC api couldn't handle a
> more sane organization of the maintenance data.
>
> I'm not suggestion a local Berkeley database or
> anything, but a more compact format _outside_ our
> project file structure!
>
> ---
> Still in love with Subversion
>
>
>
> Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
Alvin Thompson
Navy: 34
Army: 6
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 8 18:18:56 2004