Re: Our SVN layout is not that smart OR should we change the SVN layout? (take 2)
On Sun, Jun 25, 2006, Eddy Petrişor wrote:
> I am sorry, I have had examples in the past when this kind of
> announcemnt just went without answer, probably this is a reason behind
> my hastly actions.
It's all right. I'm seldom pissed for more than 2 hours anyway :)
> OTOH, D-I, base-config, dpkg use the classical SVN layout, so there
> are example both ways;
But they're fully hosted projects, aren't they?
> If you want we can discuss the change to that (I have learned my
> lesson and will not haste it now :-) )
I can give other reasons why I like the unstable/etch naming scheme:
when you start packaging something, you obviously put it in trunk/, even
if it only goes to experimental. Then when it enters unstable, you need
to choose between copying trunk/ into branches/experimental, which may
be nonsensical if the main development still happens in the experimetal
branch, which will be forked from time to time to unstable, or into
branches/unstable, which is inconsistent with all other packages.
However, though I imported many packages in the repository, I haven't
been here for a long time and I don't want to change other people's
habits. I believe it's possible to have both schemes in parallel if
people feel too strongly about one or the other.
> What is needed to have the svn-buildpackage fixed. AFAIUI, a
> debian/svn-deblayout file can be placed in SVN and it can be made to
> work properly, no matter who will checkout.
Right. I usually just symlink "tarballs" to "../tarballs", because
SVN can handle symlinks. And in this case, one-level branching following
Debian release names is easier, too, because only one symlink is
required for each branch name.
> For now, the tarballs directory is still in its original place.
> Although I suspect your svn-buildpackage settings will assume the
> tarballs dir to be at the same level as the packages, I feel the
> duplication is unnecessary.
Agreed.
--
Sam.
Reply to: