RE: Proposal: Subversion Migration
-Original Message- From: Andrew Ruder [mailto:[EMAIL PROTECTED] automatically. For example, I can make a /modules/dev-apps that basically says: Check out /apps/gorm/trunk into the gorm directory Check out /apps/easydiff/trunk into the easydiff directory and so on. When you do an svn update, or a commit or anything, it will commit to the actual location in the repository. svn:externals are a powerful thing when used in this regard... Yes, after looking at it a bit, I think have a separate repository for each independant 'package' would be good. Interesting, I did not realize that non-fsf-copyright-assigned projects existed in the GNUstep CVS. Perhaps to save the confusion we should set up another project for the nonfsf stuff. The modules I refer to above can reference external svn repository locations every bit as easily, so we could still make dev-libs pull in from the non-fsf place. But when setting up commit access we'd have the advantage that anyone getting the fsf gnustep commit access would need to have signed the forms, etc.. to assign copyright on code placed in that repository. Having such a project may also be an excellent place for people to host non-fsf-copyright-assigned projects directly related to gnustep. Yep. A few got in before I was thinking about how the repository should be organized. A non-fsf place sounds like a good idea. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Hey, On Friday, October 21, 2005, at 10:50 PM, Adam Fedor wrote: Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. Yes, I would find this very positive. That the mainstream of svn got mirrored back in CVS. Although still, we are fine with CVS on savannah. It's nice being there, despite all the problems. -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Am 23.10.2005 um 05:20 schrieb Adam Fedor:
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Subversion doesn't enforce any directory layout at all. Tags,
branches and copies are all cheap and are all the same: a bunch of
references in a new directory to what you have copied/tagged/
branched. To me, it's unclear why there's still made a difference
between tags and branches[1], but that's how the Subversion book
recommends it and it seems to be widely accepted.
Unlike CVS, Subversion numbers versions throughout the whole
repository. A bunch of files checked out have always the same
version; files get higher version numbers even without being changed.
As a result, one should tend to make small repositories, i.e. one for
each app, one for each tool, one for each lib.
That's how I understand it,
Markus
[1] IMHO, a layout like /path/to/part/{trunk,releases,branches} might
throw away some CVS relicts but fit better into reality.
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 06:50:31AM -0700, Gregory John Casamento wrote:
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Maybe someone who is familiar with svn can give a basic OK to this
layout. Greg?
I believe, that until we come up with a plan to modularize things further, we
should leave the directory layout as it is. The way I see it we have two
choices:
1) Take the CVS repository whole-cloth into the SVN repo and make any changes
incrementally from there.
2) Take the burden of a redesign/relayout now and put it into SVN in some new
layout.
The relayout during the conversion is very simple. I was only
suggesting it because sometimes it is easier to follow the history when
things have not been rearranged :)
Plus, having a trunk/branches/tags per project would be much cleaner
than having a single trunk/branches/tags for the entire project. (i.e.
if we have a single tags directory, we'll be making tags like
/tags/gnustep-gui-1.0
whereas if we lay it out properly, we'll just have
/libs/gui/tags/1.0
Likewise we wouldn't have every projects tags and branches cluttering up
every other projects tags and branches hierarchy. The cvs2svn utility
also does a decent job of figuring out which tags and branches applied
to which subprojects. i.e.
http://local.aeruder.net/websvn/listing.php?repname=gnusteppath=%2FGorm%2Ftags%2Frev=0sc=0
shows only the tags made on GORM afaict.
We can of course, reorganize in the tree and move around all the tags
and branches to the appropriate places, but that may actually be more
difficult :)
This would be easier to verify if we simply did a wholesale copy from one repo
to another. Unless you're referring to *all* of the metadata (history, etc)
for each file. That's somewhat more difficult. :)
Good point. Either way, a simple shell script or perl script can do the
grunt work.
--
Andrew Ruder
http://www.aeruder.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 01:25:20PM +0200, Markus Hitter wrote: Subversion doesn't enforce any directory layout at all. Tags, branches and copies are all cheap and are all the same: a bunch of references in a new directory to what you have copied/tagged/ branched. To me, it's unclear why there's still made a difference between tags and branches[1], but that's how the Subversion book recommends it and it seems to be widely accepted. It is mostly just a namespace/convention issue. If I look through the tags directory, I should see only unchanging things marking the actual 1.0 release or the actual 1.1 release or some marker before some major changes are merged in, etc... I know that if I check those out I won't be needing to run svn update from time to time. The branches/ directory would be similar but I could assume that they are still being worked on or will have been actively developed in the past. There is no reason to have them, just a general convention which seems to have worked well over the years. Unlike CVS, Subversion numbers versions throughout the whole repository. A bunch of files checked out have always the same version; files get higher version numbers even without being changed. As a result, one should tend to make small repositories, i.e. one for each app, one for each tool, one for each lib. You can, but svn does a good job of not making the revision #'s a pain. It is kind of weird to see the history on gorm and see that it changed at revision 11500 and 11420 and nothing inbetween, but there is no reason why that's an overly bad thing, imo. The bad thing about having small repositories is that you have to be very sure they will never have overlap (i.e. make sure that you'll never have to reorganize across repository boundaries) or you'll have yourself a mess for sure :) -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Andrew Ruder schrieb:
On Sun, Oct 23, 2005 at 06:50:31AM -0700, Gregory John Casamento wrote:
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Maybe someone who is familiar with svn can give a basic OK to this
layout. Greg?
I believe, that until we come up with a plan to modularize things further, we
should leave the directory layout as it is. The way I see it we have two
choices:
1) Take the CVS repository whole-cloth into the SVN repo and make any changes
incrementally from there.
2) Take the burden of a redesign/relayout now and put it into SVN in some new
layout.
The relayout during the conversion is very simple. I was only
suggesting it because sometimes it is easier to follow the history when
things have not been rearranged :)
Plus, having a trunk/branches/tags per project would be much cleaner
than having a single trunk/branches/tags for the entire project. (i.e.
if we have a single tags directory, we'll be making tags like
/tags/gnustep-gui-1.0
whereas if we lay it out properly, we'll just have
/libs/gui/tags/1.0
Likewise we wouldn't have every projects tags and branches cluttering up
every other projects tags and branches hierarchy. The cvs2svn utility
also does a decent job of figuring out which tags and branches applied
to which subprojects. i.e.
http://local.aeruder.net/websvn/listing.php?repname=gnusteppath=%2FGorm%2Ftags%2Frev=0sc=0
shows only the tags made on GORM afaict.
Pretty cool!
IMHO, this already looks very promising and I think a restructuring
could also be quit nice. But I don't have any good ideas about what the
structure should really look like, only unripe thoughts...
(should there be a distinction between:
libs/frameworks - tendency: no
tools/apps/servers - tendency: maybe
dev/user - tendency: maybe not)
I do think it would be good time to distinguish the non-FSF copyright
assigned projects like extensions and gsantlr. That could also be a
place where I could put the GPL'ed MySQL Adaptor for GDL2.
Anyway I'm looking forward to a transition to subversion and since the
FSF doesn't have any reservations about the source being hosted at
gna.org, I withdraw mine.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 10:17:08PM +0200, David Ayers wrote: libs/frameworks - tendency: no tools/apps/servers - tendency: maybe dev/user - tendency: maybe not) nah, I think we will run into issues if we try to subdivide too much and make it only harder to do a checkout. Organizational things like that can also be partially accomplished by having modules in a /modules directory that when checked out would checkout all the other locations automatically. For example, I can make a /modules/dev-apps that basically says: Check out /apps/gorm/trunk into the gorm directory Check out /apps/easydiff/trunk into the easydiff directory and so on. When you do an svn update, or a commit or anything, it will commit to the actual location in the repository. svn:externals are a powerful thing when used in this regard... I do think it would be good time to distinguish the non-FSF copyright assigned projects like extensions and gsantlr. That could also be a place where I could put the GPL'ed MySQL Adaptor for GDL2. Interesting, I did not realize that non-fsf-copyright-assigned projects existed in the GNUstep CVS. Perhaps to save the confusion we should set up another project for the nonfsf stuff. The modules I refer to above can reference external svn repository locations every bit as easily, so we could still make dev-libs pull in from the non-fsf place. But when setting up commit access we'd have the advantage that anyone getting the fsf gnustep commit access would need to have signed the forms, etc.. to assign copyright on code placed in that repository. Having such a project may also be an excellent place for people to host non-fsf-copyright-assigned projects directly related to gnustep. Thoughts? - Andy -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On 23. Okt 2005, at 13:25 Uhr, Markus Hitter wrote: Unlike CVS, Subversion numbers versions throughout the whole repository. A bunch of files checked out have always the same version; files get higher version numbers even without being changed. As a result, one should tend to make small repositories, i.e. one for each app, one for each tool, one for each lib. Exactly. But notable repositories can refer each other so that other repositories are checked out automagically as subtrees. So the user doesn't usually need to be concerned about the actual repository a source comes from. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Le 21 oct. 05 à 22:50, Adam Fedor a écrit : On 2005-10-18 18:36:23 -0600 Andrew Ruder [EMAIL PROTECTED] wrote: * Gna.org's hosting service has been nixed more or less by most. I don't think that this is worth pursuing because of the overall negative response. I've think I've forgotten - why was gna.org nixed? I wouldn't be so negative about GNA, they are a bit understaffed but less than Savannah (I remember one or two days commit mails interruption this year). However there is a minor issue, you can reach the web site only through 'https' it seems, which means the initial connection is slow (but not subsequent pages load). The reason I ask is that I talked to RMS and surprisingly, he's not opposed to us moving the repository if we really want to, although he would prefer us going to gna.org. He does not like sourceware.org Why he doesn't like sourceware.org ? We should also talk about all the implications this might involve. For instance, the current CVS archive at savannah will still be there, so we have to inform people about that. Yes. Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. GNA provides daily snaphots of repositories automatically, may be that can be tweaked in a way which allows us to do daily repository part snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. iirc they are tools to synchronize between cvs and svn repositories. Otherwise SVK would be able to do it. Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Adam, --- Adam Fedor [EMAIL PROTECTED] wrote: On 2005-10-18 18:36:23 -0600 Andrew Ruder [EMAIL PROTECTED] wrote: * Gna.org's hosting service has been nixed more or less by most. I don't think that this is worth pursuing because of the overall negative response. I've think I've forgotten - why was gna.org nixed? The reason I ask is that I talked to RMS and surprisingly, he's not opposed to us moving the repository if we really want to, although he would prefer us going to gna.org. He does not like sourceware.org We should also talk about all the implications this might involve. For instance, the current CVS archive at savannah will still be there, so we have to inform people about that. We could probably have savannah-hackers put something on the page saying that this project has been moved. Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. We should probably just move to SVN outright. I'm still not sure I want to leave savannah, but they're so understaffed, it seems like it could be a long long time before they have a useful system working. Quite true. P.S. More complete email to follow... I've got to go put the kids to bed. :) Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Fri, Oct 21, 2005 at 02:50:39PM -0600, Adam Fedor wrote:
On 2005-10-18 18:36:23 -0600 Andrew Ruder [EMAIL PROTECTED] wrote:
* Gna.org's hosting service has been nixed more or less by most. I
don't think that this is worth pursuing because of the overall
negative response.
I've think I've forgotten - why was gna.org nixed? The reason I ask is
that I talked to RMS and surprisingly, he's not opposed to us moving
the repository if we really want to, although he would prefer us going
to gna.org. He does not like sourceware.org
People were rather hesitant to move off of savannah. As this may not be
a problem with RMS, perhaps gna.org would be the way to go.
We should also talk about all the implications this might involve. For
instance, the current CVS archive at savannah will still be there, so
we have to inform people about that.
Perhaps we can have the savannah folks disable it?
Plus we can't say, 'just update from CVS' to everyone who has a
problem anymore. Most people won't have svn, even if they knew how to
do that stuff. We need to update things like the daily snapshots.
Well, gna.org does have daily snapshots, we will probably have to work
out what they are taking snapshots of with them. Subversion is becoming
more and more standard in distributions. Most modern linux
distributions will either have it included or easily available, I
believe.
I wonder if we could still mirror the repository on CVS? Either at gna
or savannah. Even if it is read-only.
Is there any reason to keep the CVS access? Ideally we should just move
full over. If there are some people that don't like it, tough. They
can adjust ;)
For the most part, snapshots should fulfill the task of telling people
to upgrade to the latest if they really can't install subversion. The
idea of source-code management is to make life easy for -developers-,
users should just be waiting for the release or they can accept that
they may need to compile an additional tool (svn).
I'm still not sure I want to leave savannah, but they're so
understaffed, it seems like it could be a long long time before they
have a useful system working.
Is there anything in particular keeping you at savannah? The way I see
it, if savannah is unable to keep up with changing times and there is
another FSF ran service that can, there's really no reason to feel like
we must stay with savannah. Of course, maybe there are other reasons as
well...
In other news, when we want to make the transition, give me a holler,
I'll grab the latest cvs backup, and handle the conversion. It takes
a few hours to do something as large as gnustep with full history and
the dumpfile will be around ~60 megs gzipped so it may need to be
coordinated with the gna.org people somewhat and make sure they realize
that we've got something this big to start with (and it'll probably take
them a while to get the actual svn repos up and going from the
dumpfile). If we decide to make the move, I can contact the gna.org
people.
I was thinking some sort of layout like:
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
which would actually pull in the trunk from all the other locations.
(Using svn:externals) That way -base is in its own hierarchy, but you
can easily pull in /modules/core and get something similar to pulling
the core directory in cvs.
Also, perhaps something like:
/developer/username
for anyone that would like a place to experiment...
I'm fully in support of this move, and I think it would really aid
development ease and speed (after some initial adjustment).
- Andy
--
Andrew Ruder
http://www.aeruder.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Oct 22, 2005, at 7:56 PM, Andrew Ruder wrote:
Perhaps we can have the savannah folks disable it?
No, they will not do that. We could just as easily decide to make our
project non-free and then tell everyone to delete their free copies of
the project. I don't think that would go over well :-)
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Were will we actually be transferring this project to?
i.e.: Are we going to create a gnustep project on gna?
Who will be admin and who will determine access rights?
How will we verify that the transfer was correct?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sat, Oct 22, 2005 at 08:56:50PM -0500, Andrew Ruder wrote: Is there anything in particular keeping you at savannah? The way I see it, if savannah is unable to keep up with changing times and there is another FSF ran service that can, there's really no reason to feel like we must stay with savannah. Of course, maybe there are other reasons as well... FWIW, savannah is down right now ;) -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Gregory John Casamento wrote: Adam, --- Adam Fedor [EMAIL PROTECTED] wrote: On 2005-10-18 18:36:23 -0600 Andrew Ruder [EMAIL PROTECTED] wrote: * Gna.org's hosting service has been nixed more or less by most. I don't think that this is worth pursuing because of the overall negative response. I've think I've forgotten - why was gna.org nixed? The reason I ask is that I talked to RMS and surprisingly, he's not opposed to us moving the repository if we really want to, although he would prefer us going to gna.org. He does not like sourceware.org We should also talk about all the implications this might involve. For instance, the current CVS archive at savannah will still be there, so we have to inform people about that. We could probably have savannah-hackers put something on the page saying that this project has been moved. This is what permanent HTTP redirects are for. Please, if we were to go the route of moving, don't request that a nasty page with a please click on the link below or a meta-redirect be set up when there is a proper solution (HTTP redirect, which is a one-liner, specified in the apache config for http://savannah.gnu.org/projects/wherever (as I write this, savannah seems to be offline, as I cannot visit it via HTTP or HTTPS nor ping it) Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. We should probably just move to SVN outright. Yes, what's the point of mirroring to CVS, when there are snapshots? It seems like a massive waste of time. We shouldn't be encouraging people to use CVS/SVN anyways. I'm still not sure I want to leave savannah, but they're so understaffed, it seems like it could be a long long time before they have a useful system working. Quite true. Yes, and their understaffedness isn't likely to change any time soon, either. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sat, Oct 22, 2005 at 09:20:53PM -0600, Adam Fedor wrote:
No, they will not do that. We could just as easily decide to make our
project non-free and then tell everyone to delete their free copies of
the project. I don't think that would go over well :-)
Ah, well, I think most of the developers will catch on pretty quick ;)
We can put up some README.MOVED files in various places perhaps?
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Maybe someone who is familiar with svn can give a basic OK to this
layout. Greg?
Were will we actually be transferring this project to?
i.e.: Are we going to create a gnustep project on gna?
Who will be admin and who will determine access rights?
There is a gnustep gna project already. I'm sure Alex Perez (who has it
registered) wouldn't mind setting you up as administrator and some other
people that could give out the commit access although we'll have to ask
him.
Alex set the gnustep project up on gna due to Savannah not being able to
set up a -ui and -packagers mailing list when they were needed some time
ago.
How will we verify that the transfer was correct?
I'm not sure what the best approach would be here. Subversion has
repository-wide revision numbers, so it is difficult to check that
(although the original CVS revision number will be stored in the
metadata for the file). I can run a couple diffs on various different
dates through the history (including the latest) svn vs. cvs?
- Andy
--
Andrew Ruder
http://www.aeruder.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Alex, --- Alex Perez [EMAIL PROTECTED] wrote: This is what permanent HTTP redirects are for. Please, if we were to go the route of moving, don't request that a nasty page with a please click on the link below or a meta-redirect be set up when there is a proper solution (HTTP redirect, which is a one-liner, specified in the apache config for http://savannah.gnu.org/projects/wherever (as I write this, savannah seems to be offline, as I cannot visit it via HTTP or HTTPS nor ping it) While I agree in circumstances where the webpage is entirely under our control that a HTTP redirect is the best solution, I suggested this because it doesn't seem likely to me that they will put up such a redirect. What we ultimately end up doing to get people to go to the gna.org site instead of savannah is entirely dependant on what the savannah folks are willing to change. We should have a look at what other projects which have moved in the past have done to address this precise issue. Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On 2005-10-18 18:36:23 -0600 Andrew Ruder [EMAIL PROTECTED] wrote: * Gna.org's hosting service has been nixed more or less by most. I don't think that this is worth pursuing because of the overall negative response. I've think I've forgotten - why was gna.org nixed? The reason I ask is that I talked to RMS and surprisingly, he's not opposed to us moving the repository if we really want to, although he would prefer us going to gna.org. He does not like sourceware.org We should also talk about all the implications this might involve. For instance, the current CVS archive at savannah will still be there, so we have to inform people about that. Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. I'm still not sure I want to leave savannah, but they're so understaffed, it seems like it could be a long long time before they have a useful system working. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
