[packagers] Infrastructure - version control

Dag Wieers dag at wieers.com
Mon Apr 4 11:25:04 CEST 2011


On Sun, 3 Apr 2011, Yury V. Zaytsev wrote:

> I have been working in the background on implementing a better version
> control for RPMForge. I now think I have got to the point when I have
> something to show. So let us jump straight to the results and if you
> want to know about the theory, please just keep on reading.
>
> I have converted the most substantial part of the subversion repository
> that we have now to git. You can clone it this way (use gitk to browse
> through the history):
>
> git clone git://github.com/zyv/rpmforge.git
>
> The GitHub page is here:
>
> https://github.com/zyv/rpmforge
>
> I have figured out the complete list of committers so far along with
> their e-mail addresses and imported all branches and tags. The initial
> 1.3 Gb svnsync got compressed to ~70 Mb.
>
> The upsides:
>
> 1) The process of obtaining the new changes now is really a matter of
> seconds: git pull and that's it. I am sick and tired of waiting for 15
> minutes until my svn working copy is fully updated.
>
> 2) It is impossible to get a collision when you have been working on
> some SPECs for some time and then you commit and overwrite someone
> else's changes. This has happened to me and Steve in the past already.
> Git just won't let you commit until you resolve the conflicts and ensure
> that the whole tree is consistent.
>
> 3) You can have private branches for free (for nothing). This mostly
> addresses Dag's point about him being unwilling to commit things before
> they are done. Just create a private branch that nobody will be able to
> see in a matter of milliseconds and commit there. When it is done,
> cherry-pick or merge.
>
> That's it. I want to know if everybody is happy with the results of this
> conversion. Please ack or tell me why not. Once we settle this, the next
> post will be on where to host it, so let's first close this and then
> discuss all the rest. Please, one thing at a time.

Yury,

Thank you for leading this effort. For me this works at least as well as 
Subversion. Even though a checkout of a sub-directory doesn't work as it 
does on Subversion, I think it is more important to focus on optimizing 
the time of the existing developers, so I agree with your analysis.

One-time contributors have more than one option anyway. For people that 
want to help out regularly, or maintain a few packages for a longer 
timeframe, having access to all packages is useful for searching for 
comparable situations in other packages.

Hosting should not be a problem, what for me is more of an issue is 
maintaining our infrastructure. Setting it up once is pretty easy, making 
sure it stays secure, we have backups and general maintenance. We need a 
few people with access to help where needed.

So we definitely need to think of organizing ourselves and creating a 
dependable backbone/foundation.

-- 
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]



More information about the packagers mailing list