Re: RFH: Where/How to setup RCS for new libfuse-ocaml package
Stéphane Glondu <email@example.com> writes:
> Goswin von Brederlow a écrit :
>> As I'm writing both upstream source and debian packaging I would like
>> to have both source and packaging in a single RCS. I also prefer svn
>> or mercurial. Beyond that I'm pretty much open to anything and welcome
> Currently, team-maintained packages are maintained with either svn or
> git, the svn workflow being kind of deprecated.
> I don't think packaging your program using svn will help you (even if
> the upstream is svn), giving the way things are done in svn (versioning
> of tarballs, non-direct access to sources). Therefore, I would recommend
> you just to do as usual, i.e. using pristine-tar / git-buildpackage.
There is no pristine tarball and I don't intend to ever release
anything without a debian dir. There is no upstream svn
repository. There is just the fully debianized source. A native Debian
> If you want to keep upstream history in the Debian package repository,
> you can try to use git-svn. But in all cases (using svn or git or
> git-svn), you'll need to have two separate VCS... unless you use git for
> upstream (as in e.g. approx).
> I am not familiar with mercurial, nor on how things are done when
> packaging Debian things with mercurial. You can have a look at  or
>  to see how things are done. This way, you could have a single
> repository for upstream and the Debian packaging. But keep in mind that
> you'll find help more easily inside the Debian OCaml Team if you use git.
Git is just fine. And upstream == Debian. Having two separate VCS just
means twice the work commiting changes so I would really like to avoid
Can git-buildpackage work on native packages? Is there a quick guide on
how to configure for that?
>  http://hg.debian.org/hg/
>  http://wiki.debian.org/Alioth/Hg
The question isn't how to create a repository but how to arange the
things you put into it.
For example for svn-buildpackage I would create
> If you do want to use mercurial and have your package team-maintained (I
> am not strongly against it, but others might object), please provide a
> quick guide with references in a README.source file, or add an appendix
> to our policy.