#include <hallo.h>
* Joey Hess [Fri, Aug 29 2003, 12:35:46PM]:
> Actually, dpkg-buildpackage does not care what you name the build
> directory of a package.
>
> Persaonally, I use just packagename for the directory names and build
> directly from them, using a collection of ugly hacks to ignore the .svn
> directories[1]. I don't really recommend that, but it works.
Question: how do you manage upstream and Debian branches? I encounter
this problem while trying to find the best concept for svn-uupdate.
The first idea was:
branches/upstream/a.b -----------------------> branches/upstream/a.c
| (svn cp + copy of new src) |
| (svn cp + .diff.gz) |
| | (svn merge w/ trunk)
V V
trunk -------------------------> updated trunk
| (svn merge with a.c)
|
V
tags/a.b-7
However, a possible implementation failed completely because of
stupideness of "svn merge". So we have to find an alternative solution
with diff&patch&cp. OTOH it is not possible to keep the version history of
every file.
Upstream versions should be tracked with svn (svn copy x y ; cd y ; svn
status | grep ^? | xargs svn add), keeping the history of the upstream
files and saving the space in the repository.
But how to proceed with changes in the files and debian directory
itself? Simplest solution: copy each upstream version a.b to a.b-c and
apply the Debian patch from the previous version. Pro: easy to be
implemented. Contra: loosing version history of the particular file(s).
Next idea: follow this pseudocode:
foreach(files modified in debian-diff) ;
if (file doesn't exist in a.c-1 yet)
"svn cp" file from a.b-7 to a.c-1
else
apply the diff part for this file on a.c-1
fi
done
Following this principle, we would preserve as much history data as
possible. Changes on upstream files are not so good visible then, but it
is better than pure patch&"svn add" approach.
Any ideas? I feel like to implement the last thing.
MfG,
Eduard.
--
Hallo Gartenzwergsammler!
Attachment:
pgpBKishL1Tyy.pgp
Description: PGP signature