#include <hallo.h>
* Loïc Minier [Fri, Mar 16 2007, 09:43:13PM]:
> tags 414581 + patch
> stop
>
> On Mon, Mar 12, 2007, Eddy Petrișor wrote:
> > Do have a patch :-D ?
>
> Attached. It fixes a couple of issues in the process:
> * Add missing declaration for $nosave in SDCommon.
> * Do not write .svn/deb-layout if nosave is set; this is the default.
> * Move $SDCommon::nosave default out of a loop.
> * Always read all configuration sources in the following order:
> ~/.svn-buildpackage.conf, "svn-bp:" SVN properties, .svn/deb-layout.
>
> I did not implement the "use a different file name such as
> .svn/deb-layout-v2" part of the initial proposal, I find it easy enough
> to rm -f .svn/deb-layout.
>
> Please test and apply the patch. I've confirmed it solves the problems
> I've seen.
Ehm, AFAICS your patch also kills the automatic storage of the config
values in the cache. But there are different stakes involved in this
issue. First, the configuration cache in .svn/deb-layout was introduced
to make the usage smoother. To not ask five times for the ssh password.
And not to wait for five ssh logins to finish even with a
passphrase-less key installation. And without requiring tricks like fsh
or SSH connection caching.
And I agree that a sticky cache is not perfect since the workdir or
repository may change, eg. the workdir may be rellocated to another URL.
And abusing the file to allow configuration overrides for people was not
the greatest idea either. Which settings should be taken from the cache?
Which from the defaults in svn props and debian/svn-deblayout?
What do you think about following concept: when reading settings,
SDCommon marks the values that have been read from the local config
files and properties, and which are learned from the repository
connections.
On exit, the .svn/deb-layout is stored containing ONLY the learned
variables, AND a fingerprint created from all the other variables,
including the URI of the working directory.
On the next start, only the settings from the local sources are
retrieved first, then the created fingerprint is compared with the one
in the cache. If something is inconsistent, the cache is nuked and the
settings need to be explored again.
OTOH thouse users who want to override variables can edit the cache,
delete the fingerprint and then the checks are disabled and we have the
current technique again.
Does this sound acceptable?
Eduard.
--
<rogge> abend, wie kann ich folgenden Fehler beheben
--> gpg: Schutzverfahren 254 wird nicht unterstützt
<Scorpi> rogge: export LC_MESSAGES=C
<rogge> Scorpi: kannst du mir auch erklären warum das so ist?
<rogge> Scorpi: es ändert sich nichts ausser dass mir den Fehler in english
anzeigt
<Scorpi> rogge: na sowas :-)
