Hello Erik,
thanks for your elaborately answer, I appreciating this.
>From the above I get the feeling you're not understanding what the
>'switch' part of my message means.
In fact, I have less practical experience with the switch command. We
use always the update command. I understand that this is a way without
using links. I must play with this first, before I can understand all
effects that this imply in depth. But I hope that I have enough
knowledge for a reasonable discussion here. Your elaborately
description of the switch use show me, it’s not a easy way too. I
would explain this:
We have 23 projects, 13 common modules and 28 third-party moduls in
our repository. Our main project use 26 modules. Because we are a two
man team, the communication between us is easy (ok, not always :-)).
Therefore we can give us the freedom that all changes in any modul
affect all projects immediately. The main directory of all our
projects have svn:externals to the used moduls. Add or delete a modul
from the project is a property change of the main directory. This
implied, that this changes is versioned by subversion (a very
brilliant feature!). Make a retail version it’s easy. We must only
make sure that all is commited and tag this. Then we can forget it and
work as before. If we need this version again (e.g. for debugging),
then we want this checkout into a new working directory. Would svn
work as I proposing, one checkout command would be the only think that
we needed. But now, after the checkout, we must look at the main
directory property. For every link (in my Example 26 times), we have
to call a "update to" command. This is what I have automated with a
tool written in Delphi. After finish the work at this wd, I delete it.
I don’t like wd’s with forgotten state.
By using switch, the checkout "task per module" effort is high and
therefore only worthwhile if we use this for a substantial non HEAD
wd. I think this is what you mean too. Ok so far, but I see two
problems (Don't hesitates to send me a RTFM):
1.At the initial check out: Where can I know what module the project
needed? With link as a main dir property I can look at this. But now,
if I can’t remember me, I must ask the compiler what file he miss.
2.You have written:
>Since svn knows these modules are related (and how!), it can easily
>update and backdate the entire working copy to every revision in the
>repository.
I think this is only correct, if the modul usage has not changed. Svn
knows only the moduls what you told it by the switch commands. The
modul usage isn’t versioned. This is a pitfall.
If I think wrong, then your switch way is attractive for me. If not,
then I can't go this way.
>> The function that check out a extermal link should recognize if is a
>> "internal link" into the same reporisitory and – if the link self has
>> no revision number – check out the version given by the command line.
>So, you're proposing an 'svn:auto-switch' property with a
>'relative-to-the-local-path' path name in it?
No. What I proposing is a little modification of the approach for the
'svn:externals' property. If its source URL point to the same
repository as the project source URL from command line, then I call
this URL a "internal link". In Szenarios like our, all 'svn:externals'
properties are "internal links" becouse we have only on repository.
I think Malcolm has understood me, he has written:
>Yup, though if we supported in-repository (relative) externals, we might
>decide that it makes sense to use the default operative revision for the
>externals in the same repository.
Of curse, if a risk that changing the approach of 'svn:externals'
properties break the compatibility to existing application, then we
must not use 'svn:externals'. But a new property involve much more effort.
>Ok. Well, the thing is: we need really good designs (which can be
>distilled from extensively described use-cases) in order to be able to
>implement the desired behaviour. Next to that, there are a number of
>big changes going on at the moment, so please don't be angry when
>we're not implementing immediately.
>
>However, if you have some time to donate, you could research both the
>mailing list archives and the issue tracker to find if there is
>discussion about what you'd like implemented already. If not, writing
>up a proposal and filing it in an issue would be a good idea.
My main goal is not a solution for myself (I have my work around
tool), rather that I can help to improve Subversion. On the Subversion
Issue Tracker web site it is written:
>We depend on the mailing list and IRC channel as a first level of
>filtering for our bug tracker. Without this filtering, the tracker
>would be full of duplicate issues, non-issues, and unreproducible
>issues. Please help us keep the bug database clean, by always
>finding a buddy before you file!
At the moment I still seek for a buddy. If I can’t find someone here,
I must accept that my idee is not good enough. Malcolm’s answer let me
hope. The discussion with you is important for me. I hope that more
list member would be interested.
I risk a look to the Subversion source code already. I'm sorry, I
can't be done without help from a insider. I's a moral certainty that
the effort for help me is bigger than for do it without me.
I hope my poor English is not a torture for the reader.
Regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 14 20:49:48 2007