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

Re: {debian,pkg}-science repository



Am Freitag, den 09.05.2008, 13:40 +0200 schrieb Manuel Prinz:

[..]
> I also do care about the VCS. Personally, I'm very happy with Git that I
> tried after last DebConf after hearing so much good things about it;
> they turned out to be true. ;) The biggest disadvantage with Subversion
> is that one can not work effectively when being offline; I also like
> Gits branching feature while experimenting with different changes in the
> package. Nevertheless, if the choice is Subversion, I can be happy with
> that too.

Shouldn't git-svn help here? I know several projects on sf.net where
authors use it to maintain the source locally with git and "online" with
subversion.

So people can choose to use svn or git for the same project (never
tested, but should be possible with some extra effort).

I like git, but subversion is IMHO the perfect choice for small
packaging projects without special needs. I mean: Why do you need
feature branches, if you just apply a few patches, which you also send
to upstream (so you can drop them with the next release). This is not
the X.org server. I'm thinking about moving to git for docbook-xsl
because of the amount of patches. But for all other packages I will
always prefer subversion for a collaborative maintenance. It's easy and
it offers some kind of shared file system. What do you need more? I
never observed the necessity of a better merge tool for such projects
(to be honest: I never observed conflicts, maybe because I/we prefer
separate patches instead of direct source manipulation).

I hope, you don't misunderstand my comment as flamebait. But before you
decide to force people to use special tools [1], you should think about
the advantages and the disadvantages and possible compromises. And I
still think, git-svn sounds like a good compromise for svn and git users
and one should check, if it maybe can be used to connect svn.d.o and
git.d.o (and if it can handle feature branches and patch systems), which
would be ideal for both sides.

[1] Ok, if one made the decision for dpatch or quilt for a package, the
others must use this patch system. But both are easy to understand and
use, so I don't consider this enforcement to be "bad".

Regards, Daniel


Reply to: