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
Received on Sat Mar 6 02:00:57 2004