On Thu, Jun 11, 2009 at 1:53 AM, Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se
> wrote:
> 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.
>
Those three options you mentioned ARE the "dependency manager". I am not
convinced there are other, better options. I've done this long enough that
you cannot convince me otherwise.
The dependency management you are talking about, after briefly looking over
Apache Ivy's website, looks like code-level dependency management. This is
not the topic on discussion here. We are talking about conceptual
dependencies and how to handle those at the earliest possible point.
Subversion, obviously, is the earliest you can handle dependencies and thus
the most reliable.
And yes, they each have their strengths and weaknesses, which is why I said
you cannot simply declare any of them a golden hammer. It's very dependent
on the project in question, and usually compromises must be made.
Uhm. He did write "may", and he is in favour of implementing it.
>
I did not mean to imply that he was not in favor of implementing it. I am
stating a general fact, that you cannot look at this from a statistical
standpoint.
> 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.
>
What afformentioned data? There is no data to show. I've already clearly
explained the benefits of having such a feature, such as TSVN lacking a
reasonable interface for this, and the fact that when this need arises, even
if it is "rare", it is still just as important.
By limiting this feature, we limit and/or frustration the options the user
has in regards to how they will version their sources and structure their
repositories. Again, this is not to say that it will not get done or that no
one currently is in favor of it, I am just stating a general fact.
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.
>
See my comment above about Ivy and dependency management. I use CMake
for this, and it works perfectly fine. But again, this isn't the topic
on discussion here. We're talking about conceptual dependencies only.
>
> > 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.
All of these issues (conceptually atomic commits, etc) are managed by your
development process. If you use continuous integration, and proper release
tagging and versioning, you can easily overcome these issues.
Backwards/forwards compatible strategies also work well here. But again,
this is not the topic on discussion.
There is one undeniable fact. If you have a project in your repository
called "Foo", and a common engine that all projects use called "Engine".
Then in order to compile "Foo", you also need a copy of "Engine". The
discussion here is merely about how these dependencies are managed in the
repository alone. Because there is no way of avoiding having to do at least
2 checkouts here. Depending on the requirements of the project hierarchy, it
is a good idea to try to minimize the amount of work needed to checkout a
project and its dependencies. The solutions I have discussed here (Sparse
directories, externals, etc) are all great ideas for solving this issue at
the earliest possible point. Doing it this way requires NO script to be made
to do the separate checkouts for you, although the script may be appropriate
in certain situations. I cannot speak for all.
> How would it complicate branching?
>
I think you and I need to get on the same page before I bother explaining.
You're not quite understanding the actual subject here and for that I
apologize. I must not be adequately explaining myself.
> 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". :-) )
>
Right, but you can't use the word "may" here as a cop-out. You can't tell
someone that, because you don't understand my requirements, for example.
That's like knowing nothing at all about how to work on cars, and you go up
to some mechanic and tell him how to do his job. It just doesn't make sense.
Just like I can't tell you a checkout script is a poor idea (I've clearly
indicated that I cannot deny its practice above), you can't say that
externals or sparse directories are a bad idea. You may feel, however, in
your personal experience that sparse directories have been rarely used or
rarely helpful. That's fine, but not everyone shares your
enthusiasm/experiences.
And to me that is a perfectly good argument not to prioritize this feature.
> ;-)
>
Again, you're being naive and selfish. Just because you do not prefer this
feature does not mean there aren't others that do. Perhaps we should take
some time to hear feedback from people.
Anyway, we're getting a bit off-topic from my initial post, and I blame
myself for that. So, let's try to keep things on track. While this is a
great philosophical discussion, we should really take it elsewhere. If you
want to continue the discussion please email me personally so we do not
cause unnecessary traffic on the mailing list.
Thanks to everyone for their interest in discussing this feature
request. As I've said all along, I realize it is a lot of work but
hopefully someone values it enough that they will work on its
implementation in the future!
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2361271
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-11 15:19:19 CEST