nick vajberg <nickvajberg@yahoo.dk> writes:
> 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"...
Sorry it's causing you problems. We can't predict when they will get
solved; there are a lot of things to do, we can't solve everything at
once.
Consider the complaint filed. If you understand (and perhaps you do)
how difficult some of these proposals are to implement, then you'll
understand why you're not making the headway you want.
(Fixing, or offering an option to fix, the ".svn" vs "_svn" problem
maybe isn't so hard, we should probably reexamine it at least for 1.1.
But don't quote me on that yet. :-) ).
I hope all this doesn't come off as "talk to the hand". I understand
how annoying these problems are. It's just that: so is lack of
reserved checkouts (locking), so is lack of merge history tracking, so
is...
You get the idea.
Best,
-Karl
> This is why: . 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
---------------------------------------------------------------------
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:45:16 2004