Re: Version control migration?
Daniel Johnson <daniel.johnson31 <at> gmail.com>
2011-02-06 19:41:28 GMT
On Feb 6, 2011, at 2:28 PM, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 2/6/11 1:53 PM, Daniel Johnson wrote:
>> As we all should know by now, Sourceforge's CVS access went down on Jan 26 due to an attack on their servers
and is still down now with no estimate of when it'll be back. Sourceforge has also indicated that they're
considering ending CVS access altogether in the near future since its architecture is inherently
fragile and insecure. Some maintainers have discussed switching to something a little less ancient for a
while now but inertia is a powerful force. :)
>> So now that our hand is being forced, I decided to just go and do something. The maintainers I've talked to
would like to use Git or Mercurial (and so would I) but after some discussions on IRC I've come to the
conclusion that our best choice is Subversion. Now wait, don't yell at me! Let me explain. Fink is a bit
different from most projects in that our users have to interact with our repository to use fink, either
through rsync or cvs. So, we need something that is easy for our users to use.
>> Subversion has two big advantages going for it from a user's perspective.
>> 1. It comes standard with the system on 10.5 and later. 10.4 users would have to 'fink install svn'.
>> 2. Sourceforge provides svn access over https on standard port 443, which means people can use it behind
firewalls. Since most firewalls block everything but 80 and 443, svn is really our only choice because
it's the ONLY service Sourceforge supports over one of those ports.
>> Subversion also behaves substantially similar to cvs so maintainers won't have to learn a whole new way
of using the repository. Git and Mercurial work differently and would require people used to only cvs to
learn a new way of doing version control. If maintainers REALLY want to use them, git-svn and
hg-subversion allow Git and Mercurial to act as svn clients.
>> gecko2 has been keeping a copy of the sf cvs repository so I was able to download that and experiment.
Converting it to svn was simple with 'cvs2svn --fallback-encoding=utf_8
--retain-conflicting-attic-files'. There are a handful of log messages with utf8 text in them, thus the
--fallback-encoding, and a few cases of files existing in both the Attic and the regular tree--a mild form
of cvs corruption. cvs2svn worked like a charm and I now have a local svn repository with full history
preserved. I then implemented a selfupdate-svn method for fink. I successfully bootstrapped fink,
switched to selfupdate-svn, switched to selfupdate-rsync, then switched back to svn without a hitch. I
can't test switching with cvs, for obvious reasons.
>> There's nothing more that can be done at the moment since both cvs and shell access are still down, and we
can't enable svn without them. I just wanted to put this out there and see what opinions other people had.
There would need to be other changes made since fink's website is generated from the sources in cvs and the
package database draws information from there as well.
> The website is just updated via a "cvs update", so that shouldn't be
> terribly difficult to handle. And the rsync mirror scripts would need
> to switch over as well.
> Would we have the ability easily to regulate commits access on a more
> fine-grained level than we're using right now? E.g. to give most
> established maintainers the ability to commit and modify their own .info
> files but not to modify those of other maintainers? That'd be a useful
> additional feature in my opinion, because we could consider broadening
> our pool of committers and thereby reduce the backlog on the tracker.
Alas, no. "At this time, SourceForge.net does not provide finer-grained permissions (e.g. restrict
access by specific paths within a repository) for Subversion. We will consider implementing
fine-grained permissions for our Subversion service based on the feedback we receive from project
developers." It looks like all Sourceforge provides is access to the whole repository. That would
actually be a step backward from cvs. :/ I guess it would be possible to have a pre-commit-hook script that
limited access to certain areas. It would have to look up whether a maintainer had access to a particular
file and could veto unauthorized commits. We would have to set that up ourselves.
BTW, I hacked fink to use gecko2's cvs copy so that I could test switching between svn and cvs; it works fine.
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
Fink-devel mailing list
Fink-devel <at> lists.sourceforge.net