On Mon, Mar 08, 2004 at 03:10:32PM -0500, Alvin Thompson wrote:
> Andreas Kostyrka wrote:
> >Well, your argument went, that there are more than enough ready to use
> >libraries to do these feat: Please name one that works well enough for
> >this.
> >(>2GB support, apr style portability, etc.)
>
> give me a while to look at the SVN code/do some research, and i'll give
> some candidates.
>
> for now, what about a 'tar' library? it doesn't compress, but it still
> addresses all the issues, and i'm pretty sure it's stable and handles
> big files...
Well, tar files as such are not designed to be updated in place :(
So no, tar files are not a sensible candidate.
> honestly, i don't know enough about apr or how it works to comment. can
> you recommend some documentation?
There seems to be only the doxygen docs at apr.apache.org.
> while i agree that it is reasonable to expect that a SVN client should
> be SVN aware, the bigger issue is, why should we require that any
> application be SVN aware? that would only limit its acceptance. the
> point i was trying to make was, if even a SVN client doesn't play well
> with the current SVN scheme, how can we expect/require that other apps
> do so?
>
> >Well, don't get personal:
>
> just playful banter. no offense intended. i like a good, heated debate
> because that's where all the brainstorming gets done.
>
> >RCS: RCS symlinks
> >CVS: CVS dirs.
> >SVN: .svn dirs.
> >Sniff: .sniff (well sniff is not actually a cms, but includes cms
> >functionality)
> >
> >So basically these CMS all have a concept of a directory inside the working
> >copy. So it's nothing special about Subversion.
>
> just because a lot of other VCS systems had this limitation is not
> justification for SVN to keep it.
Well, but there is no way around that (at least you do not want to keep the
CMS data completely out of the checkout area, which does have some painful
problems too).
Basically most developers do not perceive the .svn directory as limitation.
>
> >Well, most tools (including custom build systems for closed source shops)
> >have already the concept that it has to ignore management directories.
>
> once again, the most popular IDE on the planet does not. and as MS has
Again how do you get the impression that Visual Studio is the most popular
IDE? I mean I'd even bet with you that it is not the most popular one in
the only subset that matters (svn developers) ;)
> proven many, many times, you cannot expect them (or any other company)
> to go out of their way to ensure that other *competing* products work
> with their product. if anything, you can expect the opposite. i'm sure
> Bill Gates is *not* particularly distressed that VS7 doesn't work with
> an open-source VCS and that developers will have to use Microsoft Visual
> Source Safe instead. i don't know for sure, but i would imagine that
> fixing how a competitor's software works with their product is *not*
> high on the MS list of priorities. like it or not, VS .NET is *the* big
That's your view. But even if fixing compability with VS .NET would be
a priority, you are still advocating a HUGE change that doesn't have to do
anything with fixing it for VS. At least I've got the impression that in
some modes, VS doesn't like directories (files?) that start with a dot.
Solution: name the file/directory differently. Why would that have to do
anything with compressing .svn?
> IDE. ensuring that SVN works with it is up to SVN and no one else.
>
> >And how would your idea solve that? I mean it still lives some binary file
> >in the working copy area that some tools might find offensive. Actually to
> >some
> >tools this file might be more offensive, as the current .svn area doesn't
> >contain binary data (at least not as long you do not manage binary files).
>
> most tools treat non-source/non-config files atomically, and ignore
> files they don't understand. this is exactly the behavior we want and it
> would fix many more problems than it created, if it created any.
Well, doesn't seem so, as VS chokes on ".svn".
>
> >So how is your "solution" to replace
> >the trivial open/read/write/close operations by some library calls
> >(to a library you haven't yet specified, you just stipulated that such a
> >beast
> > exists), that work on some human unreadable file make the situation
> > better?
>
> but again, you are avoiding the central question: doesn't it make more
> sense to make SVN work with other products than to require that every
> other product on the planet be SVN-aware? AFAIK, this is the easiest way
> to do that, short of moving the .svn directories out of the source
> folders. and i think we can agree that is not where we want to go.
But you are asserting that arching the .svn directory into a binary file
is ok.
But doing so destroys the property of svn that a working area that doesn't
manage binary files is non-binary as such.
Non-binaryness is a property that many Unix-developers like. :)
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 21:57:38 2004