I play with the idea of migrating to Git all pkg-perl's packages for
some time, but still there are some blank spots. Perhaps this would be a
convenient time to discuss this possibility?
-=| Russ Allbery, Thu, Jan 24, 2008 at 03:14:43PM -0800 |=-
> I still find it really important to be able to separate out individual
> changes to feed upstream when working with a CPAN package. With quilt, I
> can do that. With git, I can do that,
How?
(I am not saying it is impossible, but every time I try to imagine how
to do it, I reach a point where quilt seems far more convenient :)
> but the team isn't using git and
> doesn't have a git respository (and has a bunch of tools that need to know
> about the repository).
The tools are there to follow us, not the opposite :)
> With Subversion, I can't do that, so just making
> the modifications directly in Subversion looks really unappealing. It
> adds to the upstream coordination work and makes it harder to cope with
> new versions for me.
Full ACK.
> Having used arch switch more now, and knowing that git's implementation of
> the same is way better, I'd be happy to generally switch to git.
These are the concerns I have about this. Please remember that I am in
favour of switching to Git, but there are details that I have trouble
with :)
* conversion from svn
TTBOMLK (L=limited), git-svn can't help us here as we use a repository
structure that is not that straight-forward. git-svn works best with:
$SVN/ trunk/ (here the main line of development goes)
branches/ (branches, one directory per branch)
tags/ (and tags, one directory per tag)
that is: one trunk, one place for all branches, one place for all
tags.
and we have (ignoring the multi-package "detail"):
$SVN/ trunk/ (same as above)
branches/
upstream/
current/ (here's the "HEAD" of the upstream branch)
1.01/ (and these are "tags" of it)
1.02/
2.00/
other branch1/ (possibly for backports, security,
other branch2/ stable-updates etc)
tags/ (these are the tags out of trunk)
Perhaps there *is* a way to convert this, however it seems far from
trivial to me.
* accounting (for a lack of better words)
right now, one has to simply run "svn up" in a checked-out trunk/ and
all packages are updated and new ones checked out. As Git would use
one repository per package, we'll need some sort of "service area"
where the list is kept.
* How are the patches to upstream sources managed (this is the "How?"
question from the beginning of this mail.
* alioth
Currently git.debian.org shows 776 repositories, this takes ~10s to
show here, perhaps half of these being due to network traffic (~430K
at approx. 1Mbit/s))
Doubling this may not be well accepted by alioth admins
* developer addoption
Although I am fine with Git, I am not sure about the others. Please
speak up if this is a concern for you.
--
dam JabberID: dam@jabber.minus273.org
Attachment:
signature.asc
Description: Digital signature