Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Hei Paul, it is not about checking out. I simply don't have the cvs option in eclipse on the src folder, while i have it for the openjump module (in the cvs explorer view of eclipse). but maybe i don't see the relaion mhm.. that's curious. I just tried with the Tortoise client and it did something with the src folder i tried to created a branch called: oj_stable_1_2_beta... or so but it does not seem like eclipse recognizes the branch??? Maybe it tagged it only locally and i need to commit it? puh.. i should read probably something on it stefan Paul Austin schrieb: Stefan, I'm not sure why in eclipse you are just checking out the src directory and not the whole OpenJump and then just setting adding src as a source folder in eclipse. Paul - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Stephan, You wrote: I am more than happy to watch the process of getting a development trunk in OpenJUMP development. That is awesome. I don't think that anyone is going to argue with your volunterring. :] You wrote: The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately. I think I am trying to describe the same thing, but not as well.I may have incorrectly referred to a stable branch and an unstable branch when what we really want is a stable code in the trunk or CVS HEAD and a branch for the unstable code. The Sunburned Surveyor P.S. - Are you a registered developer on SourceForge? You will need to be registered before we will be able to give you admin rights to the CVS repository at the JPP. On 6/4/07, Stephan Holl [EMAIL PROTECTED] wrote: Hello Sunburned, I am more than happy to watch the process of getting a development trunk in OpenJUMP development. As I am no dev (and therefor not able to voite) but a power-user I would second Saschas proposal of CVS structure: 1 monthn-month (n+1)-month --\ devel-\...---\--\-\-- \ \ \ \ \ release 1.2 ---\ \ \ \ \ \ release 1.3 The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately. I am involved in several OS software development where this structure is quite common. To introduce this now would lead into adding a branch (release_1.2) of the current HEAD. Perhaps it is not so difficult to set up nightly builds from both HEAD and release-branch? Just my 0.02 ¢ Stephan Sunburned Surveyor [EMAIL PROTECTED], [20070604-10:34:27]: I took some time to read over the chapter in the CVS manual on branching and merging. I have some comments now on the method I think we should use for the development branch in the OpenJUMP CVS. I believe that we should use the method described in Michael's option #3 in this thread. This is basically two branches in the CVS, one stable and one unstable. Developers can work on and test changes and new features in the development branch. When changes or new features have been completed in the unstable branch they can be merged into the stable branch, as long as they don't break the nightly build. (The nightly build will continue to be built from the stable branch.) Sascha wrote: I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 - 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 - 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features. I don't know how well this will work for our group of developers. I may be mistaken, but under this type of system I believe all changes or new features in the unstable branch would have to be working in a month of less after they are commited, because they will be going into the stable branch at 1 month intervals. I can forsee a situation under this sytem where we are always holding back a merge of the stable and unstable branches because one or more developers (probably me) doesn't have his stuff working and ready to commit. Then the other developers are upset because they have to wait for their changes to get into the stable brach via the merge. I would suggest this system as a possible alternative: Each developer and/or development team would be responsible for moving its changes and new features from the unstable branch to the stable branch. (I believe we could accomplish this by using some good file structure organization.) If the different developers can coordinate a universal merge from the unstable branch to the stable branch that's great, but under this system it wouldn't be forced. Every six months we will shoot for a new release of the stable branch. At this point we can update the version number of the unstable branch. Here is an example: Let's say the that we create the unstable branch of OpenJUMP today. The current revision number of the OpenJUMP CVS is 1.3. Based on what I read in the CVS manual I think our unstable branch would receive a revision number of 1.3.2. At the end of the year we make a new stable release of OpenJUMP and update the revision number of OpenJUMP to 1.4. At this point we would also update the revision number of the unstable branch to 1.4.2. Under this system there would be 3 versions of OpenJUMP available at any one point in time: [1] The latest stable release. (An annual or biannual snapshot of the
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Normally, the head is the unstable code, and any changes which have been tested get merged to the stable branch... -Craig On 6/4/07, Sunburned Surveyor [EMAIL PROTECTED] wrote: Stephan, You wrote: I am more than happy to watch the process of getting a development trunk in OpenJUMP development. That is awesome. I don't think that anyone is going to argue with your volunterring. :] You wrote: The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately. I think I am trying to describe the same thing, but not as well.I may have incorrectly referred to a stable branch and an unstable branch when what we really want is a stable code in the trunk or CVS HEAD and a branch for the unstable code. The Sunburned Surveyor P.S. - Are you a registered developer on SourceForge? You will need to be registered before we will be able to give you admin rights to the CVS repository at the JPP. On 6/4/07, Stephan Holl [EMAIL PROTECTED] wrote: Hello Sunburned, I am more than happy to watch the process of getting a development trunk in OpenJUMP development. As I am no dev (and therefor not able to voite) but a power-user I would second Saschas proposal of CVS structure: 1 monthn-month (n+1)-month --\ devel-\...---\--\-\-- \ \ \ \ \ release 1.2 ---\ \ \ \ \ \ release 1.3 The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately. I am involved in several OS software development where this structure is quite common. To introduce this now would lead into adding a branch (release_1.2) of the current HEAD. Perhaps it is not so difficult to set up nightly builds from both HEAD and release-branch? Just my 0.02 ¢ Stephan Sunburned Surveyor [EMAIL PROTECTED], [20070604-10:34:27]: I took some time to read over the chapter in the CVS manual on branching and merging. I have some comments now on the method I think we should use for the development branch in the OpenJUMP CVS. I believe that we should use the method described in Michael's option #3 in this thread. This is basically two branches in the CVS, one stable and one unstable. Developers can work on and test changes and new features in the development branch. When changes or new features have been completed in the unstable branch they can be merged into the stable branch, as long as they don't break the nightly build. (The nightly build will continue to be built from the stable branch.) Sascha wrote: I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 - 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 - 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features. I don't know how well this will work for our group of developers. I may be mistaken, but under this type of system I believe all changes or new features in the unstable branch would have to be working in a month of less after they are commited, because they will be going into the stable branch at 1 month intervals. I can forsee a situation under this sytem where we are always holding back a merge of the stable and unstable branches because one or more developers (probably me) doesn't have his stuff working and ready to commit. Then the other developers are upset because they have to wait for their changes to get into the stable brach via the merge. I would suggest this system as a possible alternative: Each developer and/or development team would be responsible for moving its changes and new features from the unstable branch to the stable branch. (I believe we could accomplish this by using some good file structure organization.) If the different developers can coordinate a universal merge from the unstable branch to the stable branch that's great, but under this system it wouldn't be forced. Every six months we will shoot for a new release of the stable branch. At this point we can update the version number of the unstable branch. Here is an example: Let's say the that we create the unstable branch of OpenJUMP today. The current revision number of the OpenJUMP CVS is 1.3. Based on what I read in the CVS manual I think our unstable branch would receive a revision number of 1.3.2. At the end of the year we make a new stable release of OpenJUMP and update the revision number of OpenJUMP
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
I would prefer the following: 1 monthn-month (n+1)-month --\ devel-\...---\--\-\-- \ \ \ \ \ release 1.2 ---\ \ \ \ \ \ release 1.3 Have one current stable and one devel branch. No support for older versions. You can do this if you have enough man power. Which we don't have at the moment. I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 - 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 - 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features. But the development/release model should not be set in stone. It depends on the man power (which hopefully will increase). All it have to be is that has to be transparent to the users. - Sascha Michaël Michaud schrieb: Hi, I can see several ways to manage stable/development versions (mainly depending on how much effort we can put in maintaining all the stuff - not much until now). Hope my ascii art will be readable 1 - The most simple (CVS must be always clean and releases are done after a period where every developper concentrate on tests and bug fixes) --- Development version (CVS) \ \ release 1.2 release 1.3 2 - Stable versions are derived from development CVS as needed (bugs fixes are done on both branches during some weeeks, but the development branche is ging on without threatening the stable one) --- Development version (CVS) \ \ ---1.2 1.3 Bug fixing 3 - Two branches (needs to take new developments of the development branch, to backport them and to test them in the stable branch) --- Development version \ \ \ \ \ \ Syncronization work --- Stable branch It seems to me that we have not enough development resource to do more than [2], but I'm not a professional developper, and I may ignore how we can organize ourself to have a stable branch and a development branch without loosing too much energy. My two cents Michaël Stefan Steiniger a écrit : Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
hei guys, while reading the eclipse doc i am not figuring out if we can use branching or if we need to setup a new module (that would contain only the src folder)? if we setup a new module... how would be the easiest way to transfer the changes to stable version does anybody have experiences with branches or something like that? stefan Stefan Steiniger schrieb: Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Hi Stefan, Sorry, I've a lot do this weekend (non IT stuff). Therefore I cannot offer concrete help before Monday. The best way of understanding CVS branching and merging is in my opinion the 5th chapter of the CVS book. [1] So long, Sascha [1] http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC54 Stefan Steiniger schrieb: hei guys, while reading the eclipse doc i am not figuring out if we can use branching or if we need to setup a new module (that would contain only the src folder)? if we setup a new module... how would be the easiest way to transfer the changes to stable version does anybody have experiences with branches or something like that? stefan Stefan Steiniger schrieb: Hei, hope it is ok to send a copy on the list. I am not sure about it, since it doubles efforts in copying and syncronizing the sources and i think nightly builts have to be somehow stable (i.e. are runnable) What would be possible is to make a new tree from the current module that contains the stable version. While the current cvs versions stays would be the instable one. Because i would not like to loose the nightly built. This would ensure that changes made are still one day afterwards avaliable to users. other oppinions? sorry if i missed some of the emails that dicussed that issue - simply to much are coming in at the time. stefan Sunburned Surveyor schrieb: Stefan, It sounds like a couple of the developers would like to have an unstable branch of the OpenJUMP code base that they could work in. Would you have a problem hosting this in the OpenJUMP CVS? If you have reasons to avoid this I will create a copy of the OpenJUMP code at the SurveyOS that can be used instead, but I think it would be easier to keep the two branches in the same repository. Let me know what you prefer. I can let the list know about our decision and make the changes needed. Thanks, Landon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
