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...
>>how does this affect portability? explain.
>
> Well, it's trivial. svn basically lives in the "apr" world. svn is
> as portable as the apr. So your magical beast would have to be as portable
> as apr, or else it would limit the portability of svn.
>
> Actually it would probably be best if it would be implemented on top of apr,
> so that any future apr ports are automatically supported, but that's not
> realistic to expect.
honestly, i don't know enough about apr or how it works to comment. can
you recommend some documentation?
>>please reread that thread. basically, since it is essentially a branch
>>of Tortoise CVS, it uses much of the same code. since cvs doesn't have
>>to worry about pristine copies or (usually) large numbers of files in
>>the .cvs directory, it uses a simple recursive algorithm when scanning
>>for files for that icon overlay feature. that slows Tortoise SVN down
>>because it doesn't ignore the .svn directories. while they probably
>>will/should fix this, it is yet another difference between the two which
>>makes the code harder to maintain. and once again, wouldn't it make more
>>sense to implement this than to require that every other program on the
>>planet be SVN aware?
>
> So you are again advocating a bug (albeit a performance bug) in Tortoise SVN
> as an argument for changing the clean and nice way svn works now?
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, 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
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
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.
> 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.
> Andreas
> a parti
--
Alvin Thompson
Navy: 34
Army: 6
---------------------------------------------------------------------
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:53:18 2004