monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] monotone-usher or usher-server and usher


From: Richard Levitte
Subject: Re: [Monotone-devel] monotone-usher or usher-server and usher
Date: Thu, 29 Dec 2011 13:29:20 +0100 (CET)

In message <address@hidden> on Wed, 28 Dec 2011 00:01:23 +0000 (UTC), Hendrik 
Boom <address@hidden> said:

hendrik> On Tue, 27 Dec 2011 11:40:16 +0100, Richard Levitte wrote:
hendrik> 
hendrik> > 
hendrik> > Yup, that's not the correct server.  The debian stuff is in
hendrik> > mtn://code.monotone.ca/debian-mtn
hendrik> > 
hendrik> > However, considering what I wrote above, that isn't enough either. A
hendrik> > quick way to do this is:
hendrik> > 
hendrik> > mtn clone
hendrik> > "mtn://code.monotone.ca/contrib?net.venge.monotone.contrib.usher" 
usher
hendrik> > cd usher
hendrik> > mtn clone "mtn://code.monotone.ca/debian-mtn?org.debian.usher" debian
hendrik> > 
hendrik> > The correct way is a little bit more complex.  Since Debian packages 
are
hendrik> > built from source distributions, the correct way is to build a source
hendrik> > distribution, unpack that, clone the debian directory inside the
hendrik> > resulting directory, then build your debian package from there (using
hendrik> > debuild or pbuilder or whatever you fancy)
hendrik> 
hendrik> So this means I make nested checkouts, without using merge-into-dir
hendrik> which was supposed to replace nested checkouts.

Yes.  The usher source branch and the debian packaging branch are to
be entirely separate.  merge-into-dir doesn't support that, and isn't
supposed to replace nested checkouts entirely, but merely the form
that's represented with CVS nested modules (supported by on the
repo).

The correct way to do the above is really as follows:

- get the usher source tarball.  One way is create it yourself:

    mtn clone "mtn://code.monotone.ca/contrib?net.venge.monotone.contrib.usher" 
usher
    cd usher
    ./configure && make dist

  of course, a debian packager would normally get the source from an
  official upstream release...

    wget http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz

- unpack the tarball somewhere

    mkdir /var/tmp/debian-usher
    cd /var/tmp/debian-usher
    tar -xvzf /PATH/TO/usher-0.99.tar.gz

- get the packaging directory

    cd usher-0.99
    mtn clone "mtn://code.monotone.ca/debian-mtn?org.debian.usher" debian

- build

    debuild # or whatever

So you see, the thing is that a debian packager is expected to get the
original source release from the official place, not from whatever
repository where history is stored and development happens.  That's
the reason the usher source branch and the usher packaging branch
should stay separate.

hendrik> Are these projects sufficiently disjoint that I should keep
hendrik> them in separate databases following the 
each-project-has-its-own-database
hendrik> best-practice?

That's really a personal choice, but considering that you might make
the mistake of slaming those branches together, then I'd say yes, keep
them in separate branches (I do that)

hendrik> Might it make netsync awkward if I don't keep them separate?

It will mostly mean that people will get confused by a suddenly
appearing debian directory in the usher source if you make a mistake
somewhere (which is possible).

hendrik> Does the local database keep track of which other database 
hendrik> separate for each branch, or is it just one for all?

The databases themselves only care about themselves and the branches
stored in them.  monotone can keep track of the databases for you if
you have them and the different workspaces registered (see NEWS).

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish



reply via email to

[Prev in Thread] Current Thread [Next in Thread]