Hello, a quick glance tells me there is no RFE I as beginner with the code could possibly implement in short time, so I want to offer my help in the host reorganisation away from SF. Maybe people can use this thread also to collect things that have to be done in this regard. My limitation is that I have no broadband internet, nor a 24h line at my hands, though. But surely there are other things to do.
I want the switch, badly, and I think it is more important than RFEs.
ralf PS: no flames or RFE discssions please in this thread
On Mon, Aug 29, 2005 at 10:43:41AM +0200, Ralf Stephan wrote:
Hello, a quick glance tells me there is no RFE I as beginner with the code could possibly implement in short time, so I want to offer my help in the host reorganisation away from SF. Maybe people can use this thread also to collect things that have to be done in this regard. My limitation is that I have no broadband internet, nor a 24h line at my hands, though. But surely there are other things to do.
I want the switch, badly, and I think it is more important than RFEs.
Well, the first order of business is to evaluate as many different providers as possible, and build a matrix of what they support, how good the support appears to be, etc.
(There is also an option that we could host some/all services ourselves, although to do that we'd need to find someone with a space in a co-lo they could provide to the project, and we'd need to acquire at least one server and find a few folks willing to help with sysadmin stuff.)
Bryce
Well, the first order of business is to evaluate as many different providers as possible, and build a matrix of what they support, how good the support appears to be, etc.
This is dependent on the versioning system.
(There is also an option that we could host some/all services ourselves, although to do that we'd need to find someone with a space in a co-lo they could provide to the project, and we'd need to acquire at least one server and find a few folks willing to help with sysadmin stuff.)
Unless we get an influx of willing sysadmins, I will not consider this option.
Other questions: Is the tracker database available in whole somewhere? There will be conversion issues, also with cvs. Does someone know if mailing list archives of closed SF projects stay available?
ralf
On Tue, Aug 30, 2005 at 09:03:21AM +0200, Ralf Stephan wrote:
Well, the first order of business is to evaluate as many different providers as possible, and build a matrix of what they support, how good the support appears to be, etc.
This is dependent on the versioning system.
True, however things are often not quite so cut and dried; we may find a given service willing or planning to add additional versioning systems.
Other questions: Is the tracker database available in whole somewhere?
We've got a script to download it that someone wrote early on in the project (we had to migrate tracker items from the Sodipodi database). There might be an easier way now.
There will be conversion issues, also with cvs.
Yes
Does someone know if mailing list archives of closed SF projects stay available?
Yes; also, I think we may be able to download or extract the messages for separate hosting.
Bryce
Bryce Harrington wrote:
On Tue, Aug 30, 2005 at 09:03:21AM +0200, Ralf Stephan wrote:
Well, the first order of business is to evaluate as many different providers as possible, and build a matrix of what they support, how good the support appears to be, etc.
This is dependent on the versioning system.
True, however things are often not quite so cut and dried; we may find a given service willing or planning to add additional versioning systems.
This desire to change comes up a lot. IMHO, there should be a -compelling- reason to switch from SF. SF's warts, tho many, are familiar, and we have learned to work with them. Some of us have been SF members for years, long before Inkscape existed. The staff has always been very friendly to us.
IMHO again, we need better reasons than "it's slow" or "SF sucks." To justify such a painful move, it should not be just for parity, but for some system that is magnitudes above what we have. If such an incredible upgrade exists, I would be quite enthusiastic about moving to it.
For example, Tigris.org has Subversion, but what else does it have?
Does someone know if mailing list archives of closed SF projects stay available?
As far as I know, projects on SF are never closed, they just go to sleep. I think that is in their policy documents.
Bob
There is no consensus for a full host switch, rather that is not at all an issue. However, there was strong desire to switch to a better versioning system, though mental had a point against subversion.
I assume there are no technical reasons against a separated cvs except conversion, but I simply have no experience with that so opinions on this issue are very welcome.
Now, a consensus on a versioning switch can only be reached if mental's argument against svn can be mollified. Mental, I thought you would look at the new systems that build upon svn and tell us if one of these solves the remaining problem for you.
Lastly, I would ask for opinions on if there should be a comprehensive overview of svn-based versioning systems being presented to the list to help reach a consensus, or is that consensus already existent, only pending mental's issue?
ralf
On Aug 31, 2005, at 12:45 AM, Ralf Stephan wrote:
Now, a consensus on a versioning switch can only be reached if mental's argument against svn can be mollified. Mental, I thought you would look at the new systems that build upon svn and tell us if one of these solves the remaining problem for you.
Lastly, I would ask for opinions on if there should be a comprehensive overview of svn-based versioning systems being presented to the list to help reach a consensus, or is that consensus already existent, only pending mental's issue?
I've used a few different systems over the years, but haven't actually put SVN through it's paces yet.
Most of it's features sound good, but enough has come up in regards to workflow-lockin to the way the SVN developers think one should work that I'm not so sure of it now.
Tools are another concern. Personally I use TkCVS extensively, and use it's UI to speed my workflow for many things (In many situations that and TortoiseCVS together can beat the pants off of WinCVS). I look periodically for a SVN client with similar capability and ease, but haven't seen one yet. And the TkCVS pages make it clear they aren't doing SVN themselves.
If anyone knows of anything current that could compare, that would be helpful.
But again, Mental's issues might just be the tip of the iceberg. I was waiting myself to see what all was presented before delving into my own research. Oh, and my main experience has been with custom RCS- wrapping systems, StarTeam, CVS (in many deployments) and Perforce.
On Wednesday 31 August 2005 09:03, Jon A. Cruz wrote:
I've used a few different systems over the years, but haven't actually put SVN through it's paces yet.
Most of it's features sound good, but enough has come up in regards to workflow-lockin to the way the SVN developers think one should work that I'm not so sure of it now.
I'm missing the lack of tags, but otherwise, it's quite nice for me, as a very small-scale version-control user. May well create problems on a larger scale that I'm not aware of.
Are specific alternatives being considered? Or are we just talking about the status quo (cvs) vs. svn? I forget why, but I gave up on Darcs quite quickly, and Arch, while cool, is probably more guilty of "workflow-lockin".
Tools are another concern. Personally I use TkCVS extensively, and use it's UI to speed my workflow for many things (In many situations that and TortoiseCVS together can beat the pants off of WinCVS). I look periodically for a SVN client with similar capability and ease, but haven't seen one yet. And the TkCVS pages make it clear they aren't doing SVN themselves.
If anyone knows of anything current that could compare, that would be helpful.
I'm not sure what special feature you're looking for from TkCVS, but there are a few decent GUI options for subversion. I believe there is a functional TortoiseSVN, for instance. RapidSVN (the official client, I think) is cross-platform, and probably relatively complete, though I know some features are missing. I use eSVN along with a few simple scripts, personally.
Jon A. Cruz indagò:
But again, Mental's issues might just be the tip of the iceberg. I was waiting myself to see what all was presented before delving into my own research. Oh, and my main experience has been with custom RCS- wrapping systems, StarTeam, CVS (in many deployments) and Perforce.
Currently on planet.debian.org there are several comments about the different SCM systems used by the developers...
On Wed, 31 Aug 2005, Emanuele Aina wrote:
Date: Wed, 31 Aug 2005 18:13:37 +0200 From: Emanuele Aina <faina.mail@...92...> To: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] host reorg
Jon A. Cruz indagò:
But again, Mental's issues might just be the tip of the iceberg. I was waiting myself to see what all was presented before delving into my own research. Oh, and my main experience has been with custom RCS- wrapping systems, StarTeam, CVS (in many deployments) and Perforce.
Currently on planet.debian.org there are several comments about the different SCM systems used by the developers...
James Henstridge http://blogs.gnome.org/jamesh has written about Version Control systems http://blogs.gnome.org/view/jamesh/2005/08/29/0
Another link which may be of interest: Gnome looks at alternatives to CVS http://live.gnome.org/Stuttgart2005/FreeformSessions/SourceCodeManagement
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 9/1/05, Alan Horkan <horkana@...44...> wrote:
[ snip ] Currently on planet.debian.org http://planet.debian.org there are
several comments about the
different SCM systems used by the developers...
has written about Version Control systems http://blogs.gnome.org/view/jamesh/2005/08/29/0
Another link which may be of interest: Gnome looks at alternatives to CVS http://live.gnome.org/Stuttgart2005/FreeformSessions/SourceCodeManagement
See Also
Case study: Mono switches to Subversion http://svn.haxx.se/dev/archive-2004-11/0745.shtml http://svn.haxx.se/dev/archive-2004-11/0766.shtml
Ben
On Sun, Sep 04, 2005 at 06:54:26PM +0100, Ben Fowler wrote:
On 9/1/05, Alan Horkan <horkana@...44...> wrote:
[ snip ] Currently on planet.debian.org http://planet.debian.org there are
several comments about the
different SCM systems used by the developers...
has written about Version Control systems http://blogs.gnome.org/view/jamesh/2005/08/29/0
Another link which may be of interest: Gnome looks at alternatives to CVS http://live.gnome.org/Stuttgart2005/FreeformSessions/SourceCodeManagement
See Also
Case study: Mono switches to Subversion http://svn.haxx.se/dev/archive-2004-11/0745.shtml http://svn.haxx.se/dev/archive-2004-11/0766.shtml
Thanks, these are very interesting links.
Would someone mind doing a quick test of cvs2svn on the Inkscape codebase and see if it works cleanly, and if not, what sorts of issues we may need to sort out?
Bryce
Bryce:
Would someone mind doing a quick test of cvs2svn on the Inkscape codebase and see if it works cleanly, and if not, what sorts of issues we may need to sort out?
I did a run on two other codebases: djvu and cimg
First summary: cvs2svn did not have problems given the right options but is somewhat slow (python). Interpolating from the larger run projects a runtime of one maybe two hours for inkscape on a 1.5GHz machine. The version used was 1.3.0 which appears to be 30% faster than 1.2.1. The repository size appears to increase up to one third (Berkeley DB). The process is not automatic as there might be conflicts from identical tag/branch names, where a restart with additional options is necessary. Also, downloading from SF stalled frequently, even with wget -c, and had to be interrupted/continued.
Now who will give me access to his broadband-connected 3 GHz machine? 2 GB are likely needed. I will install subversion (user space), cvs2svn, download the 87MB repo, convert, and report.
cimg djvu inkscape ---------------------- CVS Repo size tar.bz2 (blocks) 6556 13916 87000 CVS Repo size unpacked (blocks) 13772 71776 ? Number of CVS revisions 1039 18531 ? Time to create SVN repo dir (s) 34 675 ? Number of SVN commits 332 3828 ? SVN Repo size (blocks) 14684 96252 ?
ralf
participants (9)
-
Alan Horkan -
Ben Fowler -
Bob Jamison -
Bryce Harrington -
Colin Marquardt -
Emanuele Aina -
Jon A. Cruz -
Lee Braiden -
Ralf Stephan