Re: upstream and packaging monotone branches
Nicolas Boulenguez <nicolas.boulenguez@free.fr> writes:
> Many packages in the ada-france monotone repository rely on two
> branches:
> - $(upstream_branch) contains at least a tag for each upstream version
> - $(debian_branch) tracks changes in the ./debian/ subdirectory
>
> Working on the package starts with something like
> $ mtn -r t:foo-X.Y checkout $(dir)
> $ rm -rf $(dir)/_MTN
> $ mtn -r h:$(debian_branch) checkout $(dir)
I have everything needed to do this in the upstream Makefiles (for the
packages I maintain, anyway). You could add something similar in the
Debian makefile if you don't maintain the upstream one.
So work starts with 'make <nice target'.
> Often, the maintainer lists $(upstream_branch) files into
> "./.mtn-ignore" in the $(debian_branch), so that their names do not
> pollute "mtn list missing && mtn list unknown && mtn status" output.
> This is cumbersome, and error-prone:
> - each upstream release may add files and requires manual updating
This hasn't been a problem for me.
> - mentioning bar makes mtn ignore the ./bar file, but also all changes
> to ./debian/bar.
no, .mtn-ignore can be made directory-specific.
> - escaping special characters is not natural (dot for example)
Nothing about computers is "natural"!
Perhaps you mean "not familiar". It is not shell glob syntax, but regexp
syntax. There has been talk on the monotone mailing list about changing
it to shell syntax, but no one has stepped up yet.
> Why not merge $(upstream_branch) changes into $(debian_branch) each
> time an upstream version is released?
That is more cumbersome, in my opinion.
> Working only starts with
> $ mtn -r h:$(debian_branch) checkout dir
no change here.
> Jumping from a package version to another is easy with "mtn update
> -t$(debian_tag)" even if there has been an upstream release in
> between.
I always check out new major versions in new workspaces, so I can
compare new to old more easily.
> No ".mtn-ignore" file is needed anymore. It becomes a good thing that
> mtn reports every (most probably unwanted) change outside ./debian.
This is good, although one of the deb helpers does the same thing.
It would be nice if mtn handled nested workspaces; that would accomplish
this goal nicely.
> The mtn database size is only marginally increased for packages
> allready tracking upstream tarballs content.
True.
> The only cost I can see is an added complexity in patches handling.
> - They should be unapplied before committing
This is extremely problematic!
> - A recent dpkg unapplies all patches it has applied during the build,
> except in case of build failure. This means that a failed build will
> need a manual "quilt pop -a".
better, but not good enough.
> I guess that everyone does something like "debuild clean && mtn list
> missing && mtn list unknow && mtn status" before "mtn commit", so that
> should not be a problem.
DVC is better than these command line operations.
--
-- Stephe
Reply to: