trac multirepos and externals
Roger Oberholtzer
First a few questions:
I have a repository that is sort of a top-level organizer. It has many
repositories as externals. I seem to recall that in Trac these are
listed as properties, and they cannot be browsed. Is this the way it is
supposed to be?
The multirepos trac is still listed as the 0.12 release. However, I seem
to recall that the multirepos things were backported to the current
release. So, how much of the multirepos features are in the recently
released 0.11.6 version?
--
Roger Oberholtzer
Christian Boos
> I am a user of the multirepos trac and an considering my upgrade path.
> First a few questions:
>
> I have a repository that is sort of a top-level organizer. It has many
> repositories as externals. I seem to recall that in Trac these are
> listed as properties, and they cannot be browsed. Is this the way it is
> supposed to be?
>
With a multi-repository setup, the mapping has to be done in such a way
that you're pointing back into the same Trac (see
TracIni#svn:externals-section). Now that we store the url info for each
repository, it might be interesting to see how we could have a smarter
automatic mapping.
Search on t.e.o for svn:externals, quite a number of interesting
enhancements have already been proposed.
> The multirepos trac is still listed as the 0.12 release. However, I seem
> to recall that the multirepos things were backported to the current
> release. So, how much of the multirepos features are in the recently
> released 0.11.6 version?
>
though now that 0.11.6 is released and 0.11-stable frozen, chances are
that this will happen soon, and that 0.12 development in general will
accelerate ;-)
-- Christian
Roger Oberholtzer
> Search on t.e.o for svn:externals, quite a number of interesting
> enhancements have already been proposed.
> multirepos is still in a branch, and is not yet integrated in /trunk,
> though now that 0.11.6 is released and 0.11-stable frozen, chances are
> that this will happen soon, and that 0.12 development in general will
> accelerate ;-)
to previous 0.11.x releases have been placed in 0.12 as well. I am
running a 'recent' 0.12 multirepos trac and I think I had all (or at
least many of) the recent 0.11.x enhancements / improvements.
--
Roger Oberholtzer
Roger Oberholtzer
> enhancements have already been proposed.
the main issue I had with the externals. Since they access the repos via
http/https, and not direct svn access, they must supply a password. My
http/http access is not simply open to the world. It seems the password
is needed for every access. It is asked for each time a file in an
external repo is accessed.
--
Roger Oberholtzer
Ryan J Ollos
Roger Oberholtzer-2 wrote:
>
> I looked around and am not sure what I am looking for. I now remember
> the main issue I had with the externals. Since they access the repos via
> http/https, and not direct svn access, they must supply a password. My
> http/http access is not simply open to the world. It seems the password
> is needed for every access. It is asked for each time a file in an
> external repo is accessed.
>
Interesting to finally find someone that has [svn:external] configured and
working (even if its not working quite as nicely as you would like).
I tried and tried to get this working [1], and finally gave up, thinking
that the problem might be that the external Trac is 0.10.x ... though it
doesn't seem like that should make a difference.
Any chance you could post a working configuration here? (with the server
names changed of course!)
--
View this message in context: http://old.nabble.com/trac-multirepos-and-externals-tp26572731p27024324.html
Sent from the Trac Users mailing list archive at Nabble.com.
Roger Oberholtzer
>
>
> Roger Oberholtzer-2 wrote:
> >
> > I looked around and am not sure what I am looking for. I now remember
> > the main issue I had with the externals. Since they access the repos via
> > http/https, and not direct svn access, they must supply a password. My
> > http/http access is not simply open to the world. It seems the password
> > is needed for every access. It is asked for each time a file in an
> > external repo is accessed.
> >
>
> Interesting to finally find someone that has [svn:external] configured and
> working (even if its not working quite as nicely as you would like).
Within svn, the externals stuff works fine. At least it does in the svn
client I use on Linux.
> I tried and tried to get this working [1], and finally gave up, thinking
> that the problem might be that the external Trac is 0.10.x ... though it
> doesn't seem like that should make a difference.
>
> Any chance you could post a working configuration here? (with the server
> names changed of course!)
>
> [1]
> http://old.nabble.com/Help-with-syntax-for--svn%3Aexternals--section-of-trac.ini-ts25129963.html#a25167875
I do not see this. Perhaps this is because I am using the multirepos
trac release?
In the trac browser, I see the things directly in the repository. Then
under that trac writes:
Property svn:externals set to
followed by a list of all the externals.
If I click on one of these external links, I am taken to:
http://system/svn/externalRepo
which is the svn repo itself. I am not taken to
http://system/trac/browse/externalRepo which is what I would expect. So,
it is the svn and not the trac password that is being prompted for. It
is of little use as I do not want the svn http access. I want the trac
browser access.
So, I would not say I really have things working. Instead, I use the
multirepo version of trac. It has its own oddities. But for the most
part I can access via trac all of the stuff I have in svn.
I would prefer that the externals method worked so I could stay with the
main trac releases.
I do not have any external stuff set up in my trac config. Instead, as I
use the multirepos release, I have a [repositories] section with all the
external repos listed.
--
Roger Oberholtzer
Christian Boos
> ...
>
> I do not have any external stuff set up in my trac config. Instead, as I
> use the multirepos release, I have a [repositories] section with all the
> external repos listed.
>
>
Well, you need to tell Trac how the svn URLs should be mapped to URLs in
a Trac source browser (or any other source browser for that matter), as
there's no way it could figure that information by itself.
What's not clear in
http://trac.edgewall.org/wiki/TracIni#svn:externals-section ?
-- Christian
Roger Oberholtzer
Well, it never really worked as expected. I have tried again with:
[svn:externals]
1 = http://sto-opq-src.scc.se/svn http://www.opq.se/rsoft/browser/$path
An example external is now listed as:
PIAFmisc in http://sto-opq-src.scc.se/svn
Which seems to be what it is. The URL generated is
http://www.opq.se/rsoft/browser/PIAFmisc
However, I get this error when I follow that link:
No node PIAFmisc at revision 3
I have a number of externals, and all give the same complaint about
revision 3. I did have ?rev=$rev in the svn:externals, but that made no
difference.
In fact, all this looks odd to me. The svn externals tell the location
of the svn repository. So I do not need to tell trac that. Given that it
knows where the stuff is in the svn repo, what am I really telling it
here? Surely not where to fine something - it already knows that.
So, I am still confused about externals.
--
Roger Oberholtzer
Olemis Lang
<roger.ob...@gmail.com> wrote:
> On Tue, 2010-01-05 at 10:52 +0100, Christian Boos wrote:
>> On 1/5/2010 9:17 AM, Roger Oberholtzer wrote:
>> > ...
>
>
> In fact, all this looks odd to me. The svn externals tell the location
> of the svn repository. So I do not need to tell trac that. Given that it
> knows where the stuff is in the svn repo,
But (like `cboos` mentioned before ...) externals are in a different
format (AFAICR a URL) than Trac config (svn folder), so Trac needs to
be able to map the svn:externals URL to the SVN repos in the config in
order to build the link to the Trac browser (prepare your tomatoes ...
CMIIW)
> So, I am still confused about externals.
>
:(
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Bug fixed: GVizQL Parser was missing
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-gviz/rev/89e133708fa1?revcount=100
Roger Oberholtzer
> On Tue, Jan 5, 2010 at 10:31 AM, Roger Oberholtzer
> <roger.ob...@gmail.com> wrote:
> > On Tue, 2010-01-05 at 10:52 +0100, Christian Boos wrote:
> >> On 1/5/2010 9:17 AM, Roger Oberholtzer wrote:
> >> > ...
> >
> [...]
> >
> > In fact, all this looks odd to me. The svn externals tell the location
> > of the svn repository. So I do not need to tell trac that. Given that it
> > knows where the stuff is in the svn repo,
>
> But (like `cboos` mentioned before ...) externals are in a different
> format (AFAICR a URL) than Trac config (svn folder), so Trac needs to
> be able to map the svn:externals URL to the SVN repos in the config in
> order to build the link to the Trac browser (prepare your tomatoes ...
> CMIIW)
Nonetheless, the externals are only a reference to a repository. I would
imagine that it is the same, logically, as the strings in the trac.ini
that define any repository. Except that they come from an SVN property
rather than a trac.ini file.
Of course, my externals are all at the 'top level' in a repository. And
that need not be the case, leading to all kinds of issues.
Still, externals do not work for me. Listing each as a repository in the
multirepos Trac does work. So, in the long run, I am happy. But, still
confused about why externals do not work for me.
--
Roger Oberholtzer
Christian Boos
> On Tue, 2010-01-05 at 10:52 +0100, Christian Boos wrote:
>
>> On 1/5/2010 9:17 AM, Roger Oberholtzer wrote:
>>
>>> ...
>>>
>>> I do not have any external stuff set up in my trac config. Instead, as I
>>> use the multirepos release, I have a [repositories] section with all the
>>> external repos listed.
>>>
>>>
>>>
>> Well, you need to tell Trac how the svn URLs should be mapped to URLs in
>> a Trac source browser (or any other source browser for that matter), as
>> there's no way it could figure that information by itself.
>>
>> What's not clear in
>> http://trac.edgewall.org/wiki/TracIni#svn:externals-section ?
>>
> Well, it never really worked as expected. I have tried again with:
>
> [svn:externals]
> 1 = http://sto-opq-src.scc.se/svn http://www.opq.se/rsoft/browser/$path
>
> An example external is now listed as:
>
> PIAFmisc in http://sto-opq-src.scc.se/svn
>
> Which seems to be what it is. The URL generated is
> http://www.opq.se/rsoft/browser/PIAFmisc
>
All those are private or protected URLs, so I can't test...
But that configuration says that you must have a PIAFmisc folder
reachable at:
http://sto-opq-src.scc.se/svn/PIAFmisc
When you go on http://www.opq.se/rsoft/browser, are you actually
browsing that repository?
In which case you should see an PIAFmisc entry, and there's no reason
the above link wouldn't work.
Maybe that Trac is set up to browse another repository...
> However, I get this error when I follow that link:
>
> No node PIAFmisc at revision 3
>
> I have a number of externals, and all give the same complaint about
> revision 3. I did have ?rev=$rev in the svn:externals, but that made no
> difference.
>
> In fact, all this looks odd to me. The svn externals tell the location
> of the svn repository. So I do not need to tell trac that. Given that it
> knows where the stuff is in the svn repo, what am I really telling it
> here? Surely not where to fine something - it already knows that.
>
It could work if the svn:externals were not really external but point
somewhere else in the same repository... but as it's not a very common
situation, this optimization was not implemented (and you would do this
with relative 1.5 style links anyway... unfortunately those are not yet
supported in Trac).
I believe your misunderstanding comes from the fact that you assume that
a Trac repository browser can work as soon as it is given the URL to a
repository. But that's not the case, we don't access the svn
repositories via URLs (or more technically, using the svn_ra layer), but
directly via the filesystem (using svn_repos and svn_fs layers). See
#493 for understanding why.
So you need to map a given svn URL to a Trac (or another source browser)
that is configured to browse /that/ repository. In Trac, the
configuration is the directory containing the svn repository, and from
that, there's no way to infer the URL(s) by which this repository is
reachable (or conversely, from an URL, we can't know the location of the
repository in the filesystem). That's why we need this mapping.
In the first mail in this thread, I mentioned the possibility to reuse
the repository URL information if it is given (see #1781), but that's
for 0.12-multirepos only and yet to be done...
> So, I am still confused about externals.
>
>
Yes, but I hope the above helped ;-)
-- Christian
Olemis Lang
> On 1/5/2010 4:31 PM, Roger Oberholtzer wrote:
>> On Tue, 2010-01-05 at 10:52 +0100, Christian Boos wrote:
>>> On 1/5/2010 9:17 AM, Roger Oberholtzer wrote:
>>>>
>>>>
>>> Well, you need to tell Trac how the svn URLs should be mapped to URLs in
>>> a Trac source browser (or any other source browser for that matter), as
>>> there's no way it could figure that information by itself.
>>>
>>> What's not clear in
>>> http://trac.edgewall.org/wiki/TracIni#svn:externals-section ?
>>>
>> Well, it never really worked as expected. I have tried again with:
>>
>> [svn:externals]
>> 1 = http://sto-opq-src.scc.se/svn http://www.opq.se/rsoft/browser/$path
>>
>> An example external is now listed as:
>>
>> PIAFmisc in http://sto-opq-src.scc.se/svn
>>
>> Which seems to be what it is. The URL generated is
>> http://www.opq.se/rsoft/browser/PIAFmisc
>>
>
> All those are private or protected URLs, so I can't test...
>
The same for /me ... that's why I didn't follow
> But that configuration says that you must have a PIAFmisc folder reachable
> at:
> http://sto-opq-src.scc.se/svn/PIAFmisc
>
> When you go on http://www.opq.se/rsoft/browser, are you actually browsing
> that repository?
>
> In which case you should see an PIAFmisc entry, and there's no reason the
> above link wouldn't work.
> Maybe that Trac is set up to browse another repository...
>
That's something I found a bit bizarre ... I could not see the repos
alias, so if it's external ... but I supposed Robert was talking about
another repos (with an alias ;o)
>> However, I get this error when I follow that link:
>>
>> No node PIAFmisc at revision 3
>>
>> I have a number of externals, and all give the same complaint about
>> revision 3. I did have ?rev=$rev in the svn:externals, but that made no
>> difference.
>>
>> In fact, all this looks odd to me. The svn externals tell the location
>> of the svn repository. So I do not need to tell trac that. Given that it
>> knows where the stuff is in the svn repo, what am I really telling it
>> here? Surely not where to fine something - it already knows that.
>
[...]
>
> I believe your misunderstanding comes from the fact that you assume that a
> Trac repository browser can work as soon as it is given the URL to a
> repository. But that's not the case, we don't access the svn repositories
> via URLs (or more technically, using the svn_ra layer), but directly via the
> filesystem (using svn_repos and svn_fs layers). See #493 for understanding
> why.
>
I suppose that if the repos is managed by Hg or another DVCS (once
more impls will be ready and available ;o) then the right way to
«connect» that repo should be to schedule an e.g. `hg clone` and use
the local copy, isn't it ?
> So you need to map a given svn URL to a Trac (or another source browser)
> that is configured to browse /that/ repository. In Trac, the configuration
> is the directory containing the svn repository, and from that, there's no
> way to infer the URL(s) by which this repository is reachable (or
> conversely, from an URL, we can't know the location of the repository in the
> filesystem). That's why we need this mapping.
>
;o) ... The WebDAV | HTTP access to the SVN is managed by the web
server, so Trac cannot know the details (unless someone mention how to
map ;o)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Better ignore for `dist` and `build` ... bah!
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-gviz/rev/dd48a5c68159?revcount=100
Olemis Lang
> On Tue, Jan 5, 2010 at 12:47 PM, Christian Boos <cb...@neuf.fr> wrote:
>> On 1/5/2010 4:31 PM, Roger Oberholtzer wrote:
>>> On Tue, 2010-01-05 at 10:52 +0100, Christian Boos wrote:
>>>> On 1/5/2010 9:17 AM, Roger Oberholtzer wrote:
>>>
[...]
>>>
>>> of the svn repository. So I do not need to tell trac that. Given that it
>>> knows where the stuff is in the svn repo, what am I really telling it
>>> here? Surely not where to fine something - it already knows that.
>>
> [...]
>>
>> I believe your misunderstanding comes from the fact that you assume that a
>> Trac repository browser can work as soon as it is given the URL to a
>> repository. But that's not the case, we don't access the svn repositories
>> via URLs (or more technically, using the svn_ra layer), but directly via the
>> filesystem (using svn_repos and svn_fs layers). See #493 for understanding
>> why.
>>
>
> I suppose that if the repos is managed by Hg or another DVCS (once
> more impls will be ready and available ;o) then the right way to
> «connect» that repo should be to schedule an e.g. `hg clone`
ggrrrgggrrr ... `hg pull` ...
> and use
> the local copy, isn't it ?
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Incorporating changes introduced during last merge ;o)
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-gviz/rev/101ee06ab3f0?revcount=100
Roger Oberholtzer
On Jan 5, 2010, at 6:47 PM, Christian Boos wrote:
> hose are private or protected URLs, so I can't test...
>
> But that configuration says that you must have a PIAFmisc folder
> reachable at:
> http://sto-opq-src.scc.se/svn/PIAFmisc
I do.
> So you need to map a given svn URL to a Trac (or another source
> browser) that is configured to browse /that/ repository. In Trac,
> the configuration is the directory containing the svn repository,
> and from that, there's no way to infer the URL(s) by which this
> repository is reachable (or conversely, from an URL, we can't know
> the location of the repository in the filesystem). That's why we
> need this mapping.
Your first statement says it all - and is not so obvious from the
svn:externals docs. I thought that the svn:externals stuff was to let
this Trac manage browsing the external repo. I did not understand that
it simply was a way to redirect to a different Trac instance to browse
the external. Understanding that makes all this very clear. I think
that should be explicitly stated in the svn:externals docs. I think I
needed a hammer on the head type of statement to see what the
svn:externals is really doing.
It also means that my actual setup using the multirepos version of
Trac was the right way to go :)
--