>> 1) I believe the comment about 'good repository layout' is basically
>> saying that if they needed sparse checkout, chances are they could
>> do better by reorganizing the repository instead and get the same
>> desired result.
> I know exactly what it was saying, and as you have reworded it I still
> disagree with it.
...
> The example I gave before about multiple projects sharing a common
> code base without duplicating repository data proves this point.
I have to disagree with you here. :-)
What I think you are looking for is a dependency manager. Have a look at Apache Ivy for example. This is an application that exists exactly for the purpose you describe: Multiple projects sharing common code.
There are many aproaches to solving the "dependency management problem", where using externals is one, duplicating code is another, and putting everything in the same bag a third. I have been down all these roads, and all have different strengths and weaknesses. However; if you really are in the position you describe I would recomend you to have a look at a real dependency manager. All other solutions are, in the long run, only workarounds to the real problem.
>> I'll that that may be the case for 99% of the cases for sparse checkout,
>> but not for 100% of them so having support for sparse checkout is
>> certainly a good thing.
...
> Again, I think that trying to justify not implementing this feature based
> on supposed "statistics" or "It can always be done differently..." isn't
> going to work. These are not logical reasons.
Uhm. He did write "may", and he is in favour of implementing it.
We are constantly assesing and discussing how common (and/or "good") different use cases are to be able to move TSVN in a positive direction. Just take it for what it is. We are sharing experiences and thoughts here. Not statistically correct data. But unless you can provide the afformentioned data, I think we have to go with what we have.
>> You missed another use-case alternative to sparse checkout - scripting.
>> And it can be done on both Windows and Linux/Mac/Unix/etc.
...
> I don't see how scripting is providing you any benefit here.
What he is describing is essentially a dependency manager implemented using a scripting language. An excellent choice for you more complicated dependency needs where a of-the-shelf solution like Ivy wont fit.
> At least with externals, subversion can recognize them and update them
> recursively. With a script, the best you can do is multiple checkouts, each
> of which would require an entirely new update operation, which makes
> them even more tedious and impractical.
Integration in subversion is one of externals strong AND weak points in using them as a depencency manager. The good thing is that is becomes relatively easy to work on the entire codebase. The negative thing is that is becomes relatively easy to let the development span the entire codebase, where you will affect other projects when changing parts of the code that they depend on, and you lose the ability to do atomic comits in the process.
Externals may be a good solution for small projects or where you have very simple dependency needs. For anything bigger you'd like to go with a of-the-shelf dependency manager or a custom made scripted solution.
> Let's not even get into how this complicates branching.
How would it complicate branching?
> In general, you will never get a perfect repository. In my experience it has
> always been about compromise. I've done the hard work of experimenting
> with all of my options and I've come to respect that there is no "Golden Hammer"
> in Subversion, you literally have to design, analyze, compromise, and adapt
> your repository for each project..
Ok. Good. That we can agree on! :-)
And what I'm saying is that if you feel the urge to use sparse checkouts, it may be a good indication that it is time for a little bit more of that designing, analyzing, compromizing and adapring. (Note the word "may". :-) )
> I can tell you right now that I know a lot of people that would be more
> motivated to use sparse checkouts if there actually were an interface for it.
And to me that is a perfectly good argument not to prioritize this feature. ;-)
Hans-Emil
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2361180
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-11 08:54:46 CEST