2008/11/21 Jan Hauke Rahm <[EMAIL PROTECTED]>:
> Package: svn-buildpackage
> Version: 0.6.23
> Followup-For: Bug #501379
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA224
>
> Hey,
Hello,
> I was wondering about the same and tried to implement such a feature.
> Well, it's not that easy and the attached diff is *definitely* not
> really usable yet but it changes a bit and seems to work for a few
> things at least:
I have a somewhat weird/crazy suggestion.
svn-buildpackage it team collab-maintained and hasn't seen and love lately.
Since this bug proposes to add branches support to svn-buildpackage, I
guess is reasonable to prove the functionality by adding it to the
svn-buildpackage in a branch and at the end show us that svn-buildpackage
can be built from that branch.
What do you say? Do you have an account on alioth? If you do, you should
request to be added to the collab-maint group.
The URI should be (if you have an account on alioth)
svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk/
> * "svn-inject -b branch" would import the source to the specified branch
> instead of trunk and checkout the same directory
> * "svn-upgrade -b branch" would upgrade the specified branch instead of
> trunk
> * svn-buildpackage should be usable in a checkout of branches/foo
I've looked hastily over the patch and I have a question.
*Functionally* wouldn't only this part (and the code for the added
option) be enough?
- $trunkdir = "$package/trunk";
+ # NB: no :)
+ $workingdir="$package/trunk";
+ $workingdir="$package/branches/$opt_branch" if ($opt_branch);
withecho "svn up";
I mean, the rename of trunkDir into workingDir, although meaningful, might break
existent checkouts with overrides, wouldn't it? (Let me explain.)
(Later I understood that my fear might be unjustified, but still I
feel there's something
there.)
I know we're talking about a branch, and you'd generally make a new one, or make
another checkout, but is expected that if I have trunk and then svn
switch to a branch
that someone created based on the old trunk, my copy should work, shouldn't it?
If there are overrides or debian/svn-deblayout exists, then the
branches-enabled svn-bp
wouldn't work, would it, since it will have references to obsolete
layout info (trunkUrl
or trunkDir) right?
trunkUrl seems reasonble to fail, but what about trunkDir?
Still, now, that I've written these ideas, it seems like there
wouldn't be a reason to
override trunkDir and should be generated each time...
> Again: this is *not* ready but maybe it's a start for a new great
> feature.
Looks OK until now.
- --svn-only-tag Tags the current trunk directory without building
+ --svn-only-tag Tags the current working directory without building
This isn't technically correct, although svn-bp tags something which might
be the trunk (see #478697), it certainly doesn't tag the working directory
either.
I guess the most sane thing to do it would be to target fixing #478697, too,
while you're adding the branch feature, too.
Also, although "trunk" might be hardcoded throughout svn-bp's code, I feel
uneasy about hardcoding "branches" since it would farther us from a possible
fix for "#365116 -- svn-inject should allow an arbitrary layout".
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
