On Saturday 06 October 2001 22:17, you wrote:

> The latter repligard_withsg.xml has been used. Since you didnot comment
> the ambigous behaviour about the sitergroup field it seems _not_ to be a
> problem how I removed this sitegroup reference. I replaced every
> occurence of <sitegroup>[0-9a-z]*</sitegroup> against
> <sitegroup></sitegroup> and the resource allocation error vanished with
> it. However the question leaves why I had to do so ?

I didn't answer that part because I don't know how it works. Alexander will 
have to fill this gap.

> If you have a look  at http://insight.kn-bremen.de:8080/Guild/home you
> will not find mgd_include_snippet missing. Instead the function
> bremgard_page_walk that should have been included and that can be found
> e.g. using asgard is reported to be undefined. Asgard itself on the site
> wouldnot work if mgd_include_snippet would be really missing. 

Right. The bremgard_page_walk is defined in a snippet?

> The
> problem seems to come from the fact that the string to the path in
> mgd_include_snippet is not checked or cannot be checked now (Beside the
> fact that the path is found by tracking it inside of asgard). I will do
> some analysis on it e.g. by moving the bremgard-function.

You could test like $code = mgd_snippet($path). If the returned string is 
empty it couldn't find the snippet.

> The midgard release is 1.4.1 07/2001 CVS and has nothing special
> compiled.It uses e.g. --with-pagelinks. But it has not compiled on the
> target system where the target midgard is used. Instead I installed all
> midgard libs and the mod_midgard.so from the source system. Therefor no
> error should happen that cannot be found at home where the source system
> is working.  I'm afraid the problem comes from the new mixed database.
> Now it just looks mixed up sometimes.

Could be, I can't assess that without having done the upgrade procedure on 
your database.

> 1:1 backup of the target database should not be required because it
> would be rebuild by using the former sitegroup. Although there are many
> test-sitegroup on the target midgard only one sitegroup was required  to
> be saved. However I think it would be enough to import the xml-file that
> was used here into a new database with or without asgard. After creation
> of  a new sitegroup e.g. bremen import the bremgard-1.61.xml.gz.  You
> find it and repligard.conf at ftp://insight.kn-bremen.de/pub/midgard/xml

It should not be required, no, but it's usually a good idea to keep 
pre-import backups.

I downloaded the two files, and after changing the username & password 
bremgard imported without comment into my database. How should I access 
Bremgard?

> I felt at the beginning that you may have overseen my xml-patch with
> much impact. As long as it expects the source sitegroup link by GUID on
> the target system the import won't work.  Otherwise if I would not take
> it out repligard stops with the allocation error. What is the sitegroup
> link good for during import if the sitegroup should be already addressed
> more dynamic by the sitegroup login in the conf file ? However if it's
> still really required it may have been an mistake to get it out but then
> it looks like a design bug to me.

I really can't answer these questions, sorry. I know what sitegroups does but 
very little of how repligard handles them. Alexander, please step in, I'm way 
out of my depth here.

Emile


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to