Repository change to SVN, Jan 28th
I've scheduled the change of repositories from CVS to SVN for next Saturday, Jan 28. If you have any reasonably complete changes to GNUstep, you should try to commit them to the CVS repository by Friday, Jan 27. After that, the CVS repository at gnu.org will no longer be the official source code repository for GNUstep. All future development should go to the SVN repository at gna.org (which should be up on the 28th sometime). PS: This does not affect the GNUstep website, which will still be hosted at gnu.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Hello, On Saturday, January 21, 2006, at 03:47 PM, Fred Kiefer wrote: I am a bit puzzled by this fast transission over to SVN. Looks like everybody wants to take place, or at least does not oppose it. Still we should make sure that now that we doing it, it does not interrupt the GNUstep development to much. For this I would like to see a transission periode, where the offical GNUstep code is still in CVS, but there is the same code in SVN to play with. Every GNUstep developer should do a few test updates during that time and we do the actual move, when we all feel comfortable with SVN. (I know I should have been practising myself already, but I didn't) Untrue! I would prefer keeping CVS and don't bother about CVS. However I find such a transition period dangerous and difficult to manage, so a "instantaneous" switch is the best thing imho. A CVS mirror out of the SVN should be created at the same time so anonymous check-out can continue "as usual". Have fun, R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Fred Kiefer wrote: I also think that with the new possibilities of SVN there come a few more rules that we need to set up and follow. We expect that SVN will make it easier to have multiple branches with actual development going on. Now what will be the rules for merging this branches back into the main trunk? At work we are using ClearCase and have rather complicated procedures that have to be followed to make this step save. Something simpler might be enough for GNUstep. At least all changes from the trunk need to be merged down first, conficts resolved and the code tested. Then a review could happen, before the changes get actually merged. Actually, I think Fred has raised a good point here. We do, I think, need some clarification about branches and merging back to trunk. A few additional rules and guidelines may be useful. I've some questions: - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' - how are branches to be named? What about sub-branches? - how are developers going to communicate about branches and what's going on in them? - what goes into tag? When? - Are we going to import more vendor trees? (like ffcall, portaudio etc) Things to think about. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Dear Riccardo, Riccardo wrote: > On Saturday, January 21, 2006, at 03:47 PM, Fred Kiefer wrote: > >> I am a bit puzzled by this fast transission over to SVN. Looks like >> everybody wants to take place, or at least does not oppose it. Still we >> should make sure that now that we doing it, it does not interrupt the >> GNUstep development to much. For this I would like to see a transission >> periode, where the offical GNUstep code is still in CVS, but there is >> the same code in SVN to play with. Every GNUstep developer should do a >> few test updates during that time and we do the actual move, when we all >> feel comfortable with SVN. (I know I should have been practising myself >> already, but I didn't) >> > > Untrue! I would prefer keeping CVS and don't bother about CVS. However I > find such a transition period dangerous and difficult to manage, so a > "instantaneous" switch is the best thing imho. A CVS mirror out of the > SVN should be created at the same time so anonymous check-out can > continue "as usual". > Could you please explain the word "untrue"? I was mostly stating what I think should happen. Now untrue in that sense could only mean that you don't think that I want what I state. That is strange. Now, if you don't agree on what I think this is completly exceptable to me. Here the reason may be that I did not express myself clear enough. What I suggested, is a period, where all the code is available in SVN for everybody to play around and familiarize with. All changes in SVN will be thrown away later on. During that time changes may still be done in CVS. At the end of the periode the SVN repository gets replaced with a new extract from CVS and CVS will become a read only system. The benefit of this approach would be that any problems we uncover in our SVN setup, wont stop the GNUstep development until they get resolved. They will just extend the transition period. My initial suggestion for the lenght of this period would be two weeks. And only if somebody has actual problems, we would discuss about enlarging that time. The only drawback I see is that the transfer of the repository needs to be done twice. I don't see anything that might be "dangerous or difficult" with this approach. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Sheldon Gill schrieb: > Fred Kiefer wrote: > >> I also think that with the new possibilities of SVN there come a few >> more rules that we need to set up and follow. We expect that SVN will >> make it easier to have multiple branches with actual development going >> on. Now what will be the rules for merging this branches back into the >> main trunk? At work we are using ClearCase and have rather complicated >> procedures that have to be followed to make this step save. Something >> simpler might be enough for GNUstep. At least all changes from the trunk >> need to be merged down first, conficts resolved and the code tested. >> Then a review could happen, before the changes get actually merged. > > > Actually, I think Fred has raised a good point here. We do, I think, > need some clarification about branches and merging back to trunk. A few > additional rules and guidelines may be useful. I've some questions: > > - are we going to stick with the SVN recommended 'trunk', 'branch' and > 'tag' I would like to see this. > - how are branches to be named? What about sub-branches? I believe there were some suggestions before. I had no objections but also no strong feelings. > - how are developers going to communicate about branches and what's > going on in them? I would suggest the Wiki. > - what goes into tag? When? You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? > - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
On Jan 22, 2006, at 16:42, Sheldon Gill wrote: Actually, I think Fred has raised a good point here. We do, I think, need some clarification about branches and merging back to trunk. While I agree that the point is good in general and some rules need to be set up, its not the most important point _right now_. For now, why not just apply the same conventions used as in CVS? A few additional rules and guidelines may be useful. I've some questions: - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' This seems like a rather obvious yes? - how are branches to be named? What about sub-branches? Same like CVS? - how are developers going to communicate about branches and what's going on in them? Same like CVS? - what goes into tag? When? Same like CVS? - Are we going to import more vendor trees? (like ffcall, portaudio etc) What would be the rational and why would that be different to CVS? Things to think about. Yes, but not relevant to the migration itself? 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: Repository change to SVN, Jan 28th
On 2006-01-22 04:42:31 -0700 Riccardo <[EMAIL PROTECTED]> wrote: "instantaneous" switch is the best thing imho. A CVS mirror out of the SVN should be created at the same time so anonymous check-out can continue "as usual". Anyone who knows how to do this or if it is possible, let me know. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
David Ayers wrote: Sheldon Gill schrieb: Fred Kiefer wrote: [snip] - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' I would like to see this. So would I. The thing I was thinking about is experimental or proof-of-concept type work. At the moment it seems that mostly goes on in private sandboxes. It may be beneficial to bring some of that work into the open? - how are branches to be named? What about sub-branches? I believe there were some suggestions before. I had no objections but also no strong feelings. Neither do I but I feel a set of guidelines would be a good thing. - how are developers going to communicate about branches and what's going on in them? I would suggest the Wiki. I'm all for that. Maybe with occasional announcements to the -dev list. - what goes into tag? When? You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? Main releases are obvious. I'm wondering about branch snapshots. - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. I'm not sure we need a separate repository. Wouldn't a vendor directory tree would make the boundary equally clear? Other than that, I'm in agreement with this. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Sheldon Gill schrieb: > David Ayers wrote: > >> You mean other than releases? Well since we have defined repository >> states through revision numbers, I can't think of any necessity for more >> tags. It's not like gnustep is seeing the kind of development activity >> like, say, GCC. But maybe you have something specific in mind? > > > Main releases are obvious. I'm wondering about branch snapshots. Not sure why you'd want a snapshot of a branch unless your releasing from branch (as in dedicated release branches with bugfix releases à la GCC). >>> - Are we going to import more vendor trees? (like ffcall, portaudio >>> etc) >> >> >> I think we should keep anything not FSF assigned in a separate >> repository so we have clear boundaries from where we can blindly >> copy-and-paste code. Other than that I think there should be a >> dedicated maintainer(s) for any external vendor tree who will keep them >> up to date. > > > I'm not sure we need a separate repository. Wouldn't a vendor directory > tree would make the boundary equally clear? > Other than that, I'm in agreement with this. > IMO the copyright assignment boundary should be pretty clear especially if we have all projects at top level as was originally proposed, IIRC. I'm still in favor of a separate repository, but that's just my opinion. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
David Ayers wrote: Sheldon Gill schrieb: David Ayers wrote: You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? Main releases are obvious. I'm wondering about branch snapshots. Not sure why you'd want a snapshot of a branch unless your releasing from branch (as in dedicated release branches with bugfix releases à la GCC). I was thinking of two things here: One is branch releases where a branch is somewhat experimental. This would help with testing and review. The other is bugfix releases, ala GCC. - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. I'm not sure we need a separate repository. Wouldn't a vendor directory tree would make the boundary equally clear? Other than that, I'm in agreement with this. IMO the copyright assignment boundary should be pretty clear especially if we have all projects at top level as was originally proposed, IIRC. I'm still in favor of a separate repository, but that's just my opinion. Same or separate, as long as the boundary and use is clear. I wasn't thinking of having vendor items mixed in at the top level with the rest of GNUstep items. Rather a separate directory, so it's apparent they are in the Vendor tree. (Or whatever we choose to call it) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Am 22.01.2006 um 19:04 schrieb David Ayers: - what goes into tag? When? You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. Is there actually reason for tagging? As tags and branches are technically the same, shouldn't copies made according to a release go into branches/ directly? Markus - - - - - - - - - - - - - - - - - - - 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
