2009/6/19 Ryan Niebur <ryanrya...@gmail.com> >> On Fri, Jun 19, 2009 at 06:48:50PM +0300, Eddy Petrișor wrote: > > 2009/6/19 Ryan Niebur <ryanrya...@gmail.com> > > > On Fri, Jun 19, 2009 at 09:04:10AM +0200, Vincent Fourmond wrote: > > > > You see above that this looks for the ../tags directory, which is > > > > /trunk/tags. As I removed it, it works fine now so it should be safe > > > > to use svn-buildpackage. I nevertheless think it is a bug in svn-bp to > > > > look for that directory if the svn directory does not end with trunk. > > > > > > > > > > svn-buildpackage's autodetection can't be perfect, if it fails for > > > your repository you can set svn props to override the search. > > > > Yes, but should behave sanely at all times. > >
> > I suspect this is a regression as a result of the attempt to fix #433532. > > > > If that's the case, it seems the fix suggested by Joey wasn't done > > exactly in that manner. > I did the fix suggested by Joey the way he suggested, the ../tags and > ../../tags searches were already there before I started contributing. > my fix does "s/(trunk|branches|tags)/$pre/", where $pre is trunk, > tags, or branches. > > > > changing the behavior of this to not look for ../tags if the direction > > > is not trunk could very easily break somebody's (wacky) setup, so I > > > wouldn't want to do this. > > > > Think outside of the box ;-) . You don't have to literally look for > > ../tags, you could look for > > > > TRUNK_URL after s/trunk/tags/ > > > > > > This is exactly what Joey proposed and it is the sane thing to do in > > most cases, while it can be overridden via properties when using an > > unusual layout (e.g: trunk/java/package, tags/package, > > branches/java/packages) . > this is what we fall back to. however I added it as lower priority (only if > the ../tags ../../tags search fails, since that was already there). And there's your problem. The old mechanism should have been *replaced* with (or at least given lower prio than) the new one and should have been corrected with the overrides in the layout. So for short, the algo to detect tags, branches or something else is: 1. s/trunk/tags/ in the URL; does that exist? (1'. if ../tags or ../../tags exists, use that - unless next step applies) 2. see if overrides exist (svn-bp:* properties or local overrides in .svn/deb-layout) and set the target, if they do 3. if that remote directory doesn't exist, it should be created (if a write is in order - usually is) 4. be happy ;-) > > > since you are no longer affected by this would you be ok with me just > > > closing the bug? what do the other contributors to svn-bp think? > > > > Fix the bug, it doesn't matter it affects the reporter or not, it will > > hit somebody else sooner or later. > > > > I still am scared we will break somebody's setup..anyway, I'll make a > patch. What could go wrong? :-D No, really, if somebody used a weird layout without overrides, he/she was lucky and the NEWS file should give pointers to the problem; OTOH, an override, be it local or stored in layout props, should be set for that case. Regular setups should work without issues, probably except weird/unfortunate cases like "domain.tld/repos/trunk/package/trunk", which is, well, plain weird. What should it be done? Rely on only replacing the last instance of 'trunk'? Maybe the first one needed to change or maybe both? So, for plain level1 and level2 layouts or strange layouts with overrides everything should work without issues. Only non-standard layouts *without* overrides would break, but that is somewhat expected (relying on a bug) and needs fixing anyway. -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
