-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loïc Minier wrote: > On Mon, Mar 12, 2007, Eddy Petrișor wrote: >> Canyou reproduce this with 0.6.16? > > Yes. > >>> I must add that the behavior of svn-buildpackage to write a >>> .svn/deb-layout which has HIGHER precedence than debian/svn-deblayout >>> and the SVN properties is not very useful; each time >>> debian/svn-deblayout or the properties are updated or added, these are >>> not taken into account since all working copies have a >>> .svn/deb-layout... >> Is this a feature request? > > In a way, yes, definitely.
Could you find a good name for it and clone the bug? ;-) >> Having a possibility to override the settings in the repo is a >> really useful thing. Think origDir location which could be >> "../tarballs" in the repo, but you might want it to be >> "/var/cache/tarballs". > > I don't know what you mean by "override the settings in the repo". I > certainly understand that some people are happy with being able to > change the settings of their working copy via .svn/deb-layout, but I > don't see how debian/svn-deblayout or the SVN props can be useful with > the current priorities between settings sources. I understand, current behaviour is ok only for initial checkouts... > IMO, the first thing to do would be to stop creating these > automatically generated .svn/deb-layout files all over the place; they > hardcode plenty of things with no added values, quite the contrary. > For example, if i have a ../tarballs which is a symlink, > .svn/deb-layout will hold the target of the symlink! Not only was > there no need to store the default value of origDir, but dereferencing > it means that if I update my symlink, sbp will still use the old > location! Hmm, you are right, this is kind of broken... > Next, I think it makes sense to have global settings and settings at > the WC and repository levels, and it makes sense to be able to override > the settings of the repository per WC (and not the contrary) and the > global settings by the other levels. (I see now that you are using the word override with the same meaning as the one I intended ;-). > The priority for me is clearly: > 1) command-line > 2) working copy > 3) repository > 4) global settings But this way you still have the same issue, you need to clean up the working copy stuff, unless ... > The biggest problem is that each time you start svn-buildpackage, it > serializes the computed settings into the highest priority config file, > which kills all the others. > > > Another problem is that the algorithm is not to read all files and let > each other override settings, instead the algorithm is "if this file is > present, use it, otherwise continue discovery", but then some settings > are still overriden. It's very confusing. > > Perhaps the way out of this is to read all settings in reverse priority > order, stop serializing them in all cases (what's the use for saving ... you do this. This would also mean that svn-bp would be slower :-( sice would do the processing everytime the package is built. > them in files??), rename the per-WC file to .svn/deb-layout-v2 or > something else and warn when .svn/deb-layout is present. Aha, I see your point, this seems more reasonable, indeed. What do you think about an option to do what you describe on request? So you will do: svn-buildpackage --svn-reconfigure when you change the overrides or you want to import settings from the properties... - -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF9YfqY8Chqv3NRNoRAohlAKDE9QLqAxYKrjKLWioV0R01zTGT6ACfT+M7 DlgSE9b7+6M5JutrUVtwnzI= =frIj -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
