Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 01/14/2014 09:24 PM, Alexandre Rossi wrote:
> I also found out that some packages maintained
> by the team are hosted on alioth in collab-maint (src: bugz,
> dajaxice).
Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable, predicted, and unavoidable.
In fact, using collab-maint is something that I would advise right now
if nothing moves in this team.
On 01/14/2014 09:55 PM, Piotr Ożarowski wrote:
> I reported bug reports, thanks
Why doing this? It doesn't make sense. It seems obvious to me that the
person using collab-maint do want to use Git. Don't force them back to
SVN please, it wouldn't be nice to them, especially if our plan is to
migrate away from it at some point. I don't see this as a bug, I see it
as a problem in the Python team, unless the Git repo is reactivated, and
the person who deactivated it doesn't do it again.
On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> I need to spend more time playing with git-bp, but last time I looked at it
> (cannot remember which package), I had a lot of trouble unless the package
> repo was organized Just Right. One nice thing about svn-bp is that it pretty
> much just works with a checked out working directory, even when you have local
> uncommitted changes (--svn-ignore-new).
Probably you're not used enough with Git, because for what I'm doing,
"it pretty much just work with a checked out working directory" with Git
as well.
On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> git-bp OTOH required a specific set of branches inside the repo to
> stitch everything together and if those were missing, it failed
> miserably.
It all depends how you do it. If you base your Git packaging on tags,
and not using branches, which means having a debian/gbp.conf that
configures this, then it's really strait forward.
On 01/14/2014 10:31 PM, Barry Warsaw wrote:
> I've mostly made my peace with git, so in theory I wouldn't be
> opposed to the team switching
There's been a vote that we should switch already. I don't think it's a
good idea to express oneself about liking or not Git: we agreed we
should switch to it.
>, but I still think it's not a good idea
> to have some team packages in git and the bulk in svn. I value the
> ability to use the same tools and workflows for all team maintained
> packages.
Now, this could be back on the table: it's been months that we've talked
about it, and nothing is happening, because nobody has time. So the only
way I see to switch is to do it slowly, having both SVN and Git for some
time. Other teams have reported that it worked for them, so I don't see
why it wouldn't for python modules.
By the way, something like "mr" (from Joey Hess) could help regarding
mass commits.
On 01/14/2014 11:09 PM, Hans-Christoph Steiner wrote:
> I'm a fan of a gradual transition like this, with people switching or
> setting up git repos as they can.
I'm not a "fan" of it (it'd be IMO better to completely switch), but I
don't see any other practical way to move forward right now.
On 01/14/2014 11:51 PM, Olivier Berger wrote:
> It more or less requires only 2 branches : upstream (when you
> want to track upstream sources) and master (or debian) for the
> packaging source.
Hum... I'd say that *your workflow* requires it, but git-buildpackage
itself doesn't. You don't have to do this way. Everything can be
contained in a single branch if you use tags. Also, if you don't use
tags, and prefer to use upstream tarballs, then I think you're much
better off using pristine tar (and git-import-orig).
Also, I don't like using "debian" and "master" for branch names. These
express nothing. It's much better to use "unstable-debian" and
"upstream-debian" for example.
As a reference, here's a debian/gbp.conf for tags:
[DEFAULT]
debian-branch = debian/unstable
upstream-tag = %(version)s
And here's one for pristine-tar:
[DEFAULT]
upstream-branch = upstream-unstable
debian-branch = debian-unstable
pristine-tar = True
I also always add in my debian/gbp.conf:
[git-buildpackage]
export-dir = ../build-area/
to make sure no contributors dirties the git with build files (yes, you
can do that in your ~/.gbp.conf, and the system configuration file in
/etc, but the point here is to make sure *everyone* uses the build-area).
Thomas
[1] I know who it is, though I don't think it is useful to tell who.
Reply to: