Re: [MoM] Pristine Tar Updated and Uploaded
Hi Charles,
On Thu, Jul 03, 2014 at 09:56:31AM +0900, Charles Plessy wrote:
> > gbp-clone ssh://git.debian.org/git/debian-med/openemr.git
> >
> > This will give you *all* needed branches. I just realised that this is
> > not documented in our policy (which is bad - I'm a bit to tired today to fix
> > it ... I'd be happy if any volunteer would beat me in injecting this)
>
> Hi Andreas and everybody,
>
> the reason why I have not added gbp-clone previously is that I was hoping that
> we could do everything with debcheckout.
The problem in my eyes is that debcheckout only works for just uploaded
packages. In MoM we usually are dealing with not yet uploaded packages
and MoM students get the policy as main document at their hand. So
there is definitely a hole in our documentation that should be closed.
> Here is what our group policy contains
> at the moment.
>
> To clone and follow every branch of a git repository.
>
> When the package is already in the Debian archive, you can use the debcheckout
> command with its --git-track='*' option.
>
> To update the upstream, master and pristine-tar branches at once, use the gbp-pull.
>
> The difference with gbp-clone is that debcheckout --git-track='*' will track
> all the branches. Note that it will not change how much disk space is taken by
> the repository. Some of our Git repositories contain additional branches, for
> instance for Stable or Experimental uploads, backports, PPA versions, or to
> store meta-information, in particular build logs.
>
> The problem with gbp-pull is that unlike debcheckout, it does not discover the
> VCS URL of a package. This said, one could call both in a single one-liner,
> like in the following.
>
> gbp-clone $(debcheckout -da $PACKAGE | grep url | cut -f2)
>
> I was asking in #625940 to make debcheckout more convenient by tracking all
> branches by default, but this was refused with the argument that debcheckout is
> "intended to be a simple wrapper around $vcs to easily get the development
> source of a package, not much more." I am therefore tempted to move away from
> debcheckout, since its targeted user base seems to be more users than Debian
> developers.
>
> Ideally, I would prefer that our group policy would advertise either
> debcheckout or gbp-pull, but not both, so that we do not confuse the reader
> with alternatives. And the advantage of debcheckout is that it also work with
> Subversion. But maybe I am over-doing… What do you think ?
Besides the fact that I personally was ending up by unusable
repositories when I used debcheckout in the past when doing gbp-pull
later in this clone (for reasons I don't know and can not reproduce) and
thus I started to use gbp-clone exclusively I think your reasoning makes
sense in the case of uploaded packages. But since as I mentioned above
we need a solution for packages that are not yet in the archive we
should document the alternative solution via gpb-clone.
I see no problem in providing equivalent alternatives - isn't our work
always based to choose between different options? ;-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: