Re: SVN -> GIT mass conversion
>>>>> "A" == Andreas Tille <andreas@an3as.eu> writes:
Hi Andreas,
A> Hi Roland, On Tue, Mar 24, 2015 at 06:02:49PM +0100, Roland
A> Fehrenbacher wrote:
>> Hi,
>>
>> while porting DebMed packages to Qlustar, we started a mass
>> conversion of SVN to GIT package repositories. Since at the
>> St. Malo sprint I got the impression that having as much as
>> possible of the DebMed stuff managed via GIT would be desirable
>> in general, we'd also start creating new repos for these packages
>> on alioth that would allow to fully switch to GIT for these
>> packages at a certain date. The goal of this is to standardize
>> DebianMed on GIT entirely.
>>
>> The new git repos will have the standard structure with
>> master/upstream/pristine-tar branches. They will include the full
>> original SVN history and tags as well as the latest orig.tar
>> (from the current version in testing) in the pristine tar branch,
>> so that the package versions in testing will be readily
>> recreatable from them using git-buildpackage.
>>
>> We plan to do the conversion in junks of 10 packages at a time
>> and will announce these packages here in advance, so that the
>> maintainers of them and everyone else will know about it in time
>> and can check that the conversion was done properly.
>>
>> After a conversion will have been determined to be OK by all
>> parties, we should have a process to decommission the
>> corresponding SVN repo.
>>
>> If there are objections against converting certain packages (or
>> the whole idea), let's discuss it here.
A> No objection from my side. However, I personally do not see the
A> gain to port all packages. While I think we have some people who
A> remain in the SVN age I simply would consider my time wasted to
A> do a mass conversion without any obvious profit.
we won't do all packages anyway, just those relevant for clustering
(Bio, Bio-Dev, NGS, Phylo, IMG, IMG-Dev tasks). It won't be time wasted,
because we will do it anyway for our internal use, so it's just a
question whether DebMed wants to profit as well.
A> I would not stop anybody from doing this but standardisation on
A> its own would be no value in itself.
In general I think it is, since you don't need to be expert in two
VSC tools/packaging workflows and hence save time -> higher
productivity. It'll be quite a bit easier to help each other out with
bug fixes in packages not maintained by oneself.
A> Specifically if I think about several R packages which have only
A> tiny bits in SVN but may be large chunks of data in Git we just
A> fill up disk space at alioth on local disks and bandwidth for no
A> obvious win.
For some packages, it indeed might make not so much sense, that's why I'd
put them up for discussion.
A> Do you have some stronger arguments for the move which would
A> rectify this?
I don't want to get into flame wars or a deeper discussion about this
here, but for me the advantages of GIT are overwhelming and discussed at
every corner on the net. On the other hand, I definitely don't want to
force anything on any maintainer.
>> Suggestions, comments etc. are obviously welcome.
A> As I said I'm not against progress so if you do some move please
A> make sure to drop a file according to the example in
A> trunk/packages/clustalx/trunk/README.status
OK.
Best,
Roland
-------
http://www.q-leap.com / http://qlustar.com
--- HPC / Storage / Cloud Linux Cluster OS ---
Reply to: