Thread: [SSI-devel] Idiot questions about OpenSSI CVS
Brought to you by:
brucewalker,
rogertsang
From: John H. <john@Calva.COM> - 2006-12-20 16:12:00
|
In http://wiki.openssi.org/go/CVS_Administration it says: *NOTE:* /Should discuss how branches are synchronized using the MERGE-* tags. / Could someone give me some hints about what exactly is meant by this? *NOTE:* /Emphasize that before merging a branch with newer base code, all recent OpenSSI/CI changes to that branch should first be synced to all other branches. Otherwise, the recent OpenSSI/CI changes are lost in the "noise" of the base changes. / And this? |
From: John H. <john@Calva.COM> - 2006-12-20 22:26:17
|
John Hughes wrote: > In http://wiki.openssi.org/go/CVS_Administration it says: > > *NOTE:* /Should discuss how branches are synchronized using the > MERGE-* tags. > / > > Could someone give me some hints about what exactly is meant by this? If it means I should do cvs up -jMERGE-DB-FC -jOPENSSI-FC then it's pretty much a non-starter as it seems some vendor FC updates have been merged in. > > *NOTE:* /Emphasize that before merging a branch with newer base code, > all recent OpenSSI/CI changes to that branch should first be synced to > all other branches. Otherwise, the recent OpenSSI/CI changes are lost > in the "noise" of the base changes. > / > > And this? As I said OPENSSI-FC seems to have some base code merges and the debian merge tags haven't been updated. I'd guess that I just have to move the debian tags - no merge is needed. True? |
From: Karl M. <km...@gm...> - 2006-12-21 06:56:33
|
John, I am not sure if this helps at all but I had to do a very similar exercise with the SuSE port. Brian W. helped me considerably during the process. Only problem I see is that in the case of the SuSE port it was almost entirely based on Fedora 3 OpenSSI. I believe this was partly done as the distros are pretty similiar ( use rpms etc.). From the few times I have installed the Debian version of OpenSSI I noticed there are a lot more differences. The question I would ask is: was the Debian port at some point based on Fedora 3 OpenSSI? -Karl On 12/20/06, John Hughes <jo...@ca...> wrote: > > John Hughes wrote: > > In http://wiki.openssi.org/go/CVS_Administration it says: > > *NOTE:* *Should discuss how branches are synchronized using the MERGE-* > tags. > * > Could someone give me some hints about what exactly is meant by this? > > If it means I should do > > cvs up -jMERGE-DB-FC -jOPENSSI-FC > > then it's pretty much a non-starter as it seems some vendor FC updates > have been merged in. > > > *NOTE:* *Emphasize that before merging a branch with newer base code, all > recent OpenSSI/CI changes to that branch should first be synced to all other > branches. Otherwise, the recent OpenSSI/CI changes are lost in the "noise" > of the base changes. > * > And this? > > As I said OPENSSI-FC seems to have some base code merges and the debian > merge tags haven't been updated. > > I'd guess that I just have to move the debian tags - no merge is needed. > True? > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > > |
From: Aneesh K. <ane...@gm...> - 2006-12-21 09:59:04
|
On 12/21/06, John Hughes <jo...@ca...> wrote: > > John Hughes wrote: > In http://wiki.openssi.org/go/CVS_Administration it says: > > > NOTE: Should discuss how branches are synchronized using the MERGE-* tags. > Could someone give me some hints about what exactly is meant by this? > If it means I should do > > cvs up -jMERGE-DB-FC -jOPENSSI-FC > > then it's pretty much a non-starter as it seems some vendor FC updates have > been merged in. > > I will try to explain what i remember. OPENSSI-DEBIAN OPENSSI-FC OPENSSI-SU and the three distro branches in CVS. The release happens from there branches. When one make a release they tag it accordingly OPENSSI-DB-1-9-1. Now when you pushing a new release of the package for debian say logrotate you import then with tag such LOGROTATE-DB-3-7-2. This tag indicate that it is logrotate from debian of version 3.7.2. A command like below will do this tar zxf whizbang-1.2.3.tar.gz cd whizbang-1.2.3/ cvs -d $SSIREP import -d -ko -I ! -b 1.1.5 -m 'Import of whizbang 1.2.3 for Debian' openssi/whizbang DEBIAN WHIZBANG-DB-1-2-3. That 1.1.5 indicate is it debian 1.1.1 is vanilla 1.1.3 is Redhat. Now inorder to merge fixes across distribution there are merge points created as tags. MERGE-FC-DB MERGE-DB-FC Now MERGE-FC-DB is set on on Debian branch to indicate that the last merge to fedora branch happened at this point. MERGE-DB-FC is set on fedora branch to indicate that the last merge to debian happened at this point. Now before you import a new package to fedora branch or debian branch one need to make sure other branches have all the fixes needed for OpenSSI. That means if i am importing a new debian package to CVS i need to make sure that i pull all changes in fedora branch to debian and also make sure that all changes in debian is pushed to fedora branch. That means these tags should be at the top of the branch. Otherwise the next diff will show unnecessary changes with respect to distro ( this may be what you are seeing) and it will be difficult to pick the OpenSSI specific fixes that went in. Now after updating this tags you import the new package from Debian. Then you update the MERGE-FC-DB tags to point to the head of the branch. Now you add fixes that you made to the package to get it run. So at any point a diff between OPENSSI-DEBIAN and MERGE-FC-DB should show you the OpenSSI related fixes that is not yet put in the fedora branch. Now in most cases the changes needed to get the package build would already be made for the previous release. So a diff between OPENSSI-DEBIAN and DEBIAN should give you that. Make sure you do it before importing new sources from debian. Hope this explains it. It is pretty complicated isn't it ? Now wonder why viewcvs fails for our repository :) -aneesh |
From: John H. <john@Calva.COM> - 2006-12-21 11:02:41
|
Aneesh Kumar wrote: > [ much useful info ] Ok, thanks Aneesh. Lets see how badly I can screw this up :-) |
From: John H. <john@Calva.COM> - 2006-12-22 11:25:23
|
John Hughes wrote: > As for the import, I see that I should be doing an "import -X" to avoid > getting my stuff bunged into the trunk. Unfortunately Debian Sarge cvs > doesn't have the "X" option so I'll try backporting the Etch version. > So I backport Etch's cvs to Sarge, no problem, try again: CVS_RSH=ssh cvs -d -z3 -d:ext:hu...@ss...:/cvsroot/ssic-linux import -dX -ko -I! -b 1.1.5 -m "Import of e2fsprogs 1.37-2sarge1 for Debian" openssi/e2fsprogs DEBIAN E2FSPROGS-DB-1-37-2SARGE1 hu...@ss...'s password: *cvs server: invalid option -- X* Usage: cvs import [-d] [-k subst] [-I ign] [-m msg] [-b branch] [-W spec] repository vendor-tag release-tags... -d Use the file's modification time as the time of import. -k sub Set default RCS keyword substitution mode. -I ign More files to ignore (! to reset). -b bra Vendor branch id. -m msg Log message. -W spec Wrappers specification line. (Specify the --help global option for a list of other help options) Looks like sourceforge's cvs doesn't have the "-X" option. CVS_RSH=ssh cvs -d -z3 -d:ext:hu...@ss...:/cvsroot/ssic-linux version Client: Concurrent Versions System (CVS) 1.12.13 (client/server) hu...@ss...'s password: Server: Concurrent Versions System (CVS) 1.11.20 (client/server) Yow, Sourceforge has 1.11.20. Older that the Debian Sarge version. Should I import without -X and do a manual remove of e2fsprogs from the trunk? |
From: Brian J. W. <Bri...@hp...> - 2006-12-22 19:53:00
|
John Hughes wrote: > Should I import without -X and do a manual remove of e2fsprogs from the > trunk? Hi John, Manually removing cruft from the trunk after an import is what I've always done. It sounds like -X is a nice feature, but it's not necessary. Brian |
From: John H. <john@Calva.COM> - 2006-12-23 09:16:47
|
Brian J. Watson wrote: > John Hughes wrote: >> Should I import without -X and do a manual remove of e2fsprogs from >> the trunk? > > Hi John, > > Manually removing cruft from the trunk after an import is what I've > always done. It sounds like -X is a nice feature, but it's not necessary. > Ok, I'll practice this on a private copy & update the wiki when I'm confident. |
From: Brian J. W. <Bri...@hp...> - 2006-12-21 19:44:39
|
Thanks, Aneesh, for your good explanation of this complicated system. Maybe this should be posted on the OpenSSI Wiki, so that future questions can be answered with an URL. Brian Aneesh Kumar wrote: > I will try to explain what i remember. > > OPENSSI-DEBIAN OPENSSI-FC OPENSSI-SU and the three distro branches in > CVS. The release happens from there branches. When one make a release > they tag it accordingly OPENSSI-DB-1-9-1. > > Now when you pushing a new release of the package for debian say > logrotate you import then with tag such LOGROTATE-DB-3-7-2. This tag > indicate that it is logrotate from debian of version 3.7.2. A command > like below will do this > > tar zxf whizbang-1.2.3.tar.gz > cd whizbang-1.2.3/ > cvs -d $SSIREP import -d -ko -I ! -b 1.1.5 -m 'Import of whizbang > 1.2.3 for Debian' openssi/whizbang DEBIAN WHIZBANG-DB-1-2-3. > > That 1.1.5 indicate is it debian 1.1.1 is vanilla 1.1.3 is Redhat. > > > Now inorder to merge fixes across distribution there are merge points > created as tags. > MERGE-FC-DB > MERGE-DB-FC > > Now MERGE-FC-DB is set on on Debian branch to indicate that the last > merge to fedora branch happened at this point. > > MERGE-DB-FC is set on fedora branch to indicate that the last merge to > debian happened at this point. > > > Now before you import a new package to fedora branch or debian branch > one need to make sure other branches have all the fixes needed for > OpenSSI. That means if i am importing a new debian package to CVS i > need to make sure that i pull all changes in fedora branch to debian > and also make sure that all changes in debian is pushed to fedora > branch. That means these tags should be at the top of the branch. > Otherwise the next diff will show unnecessary changes with respect to > distro ( this may be what you are seeing) and it will be difficult to > pick the OpenSSI specific fixes that went in. > > Now after updating this tags you import the new package from Debian. > Then you update the MERGE-FC-DB tags to point to the head of the > branch. Now you add fixes that you made to the package to get it run. > So at any point a diff between OPENSSI-DEBIAN and MERGE-FC-DB should > show you the OpenSSI related fixes that is not yet put in the fedora > branch. > > > Now in most cases the changes needed to get the package build would > already be made for the previous release. So a diff between > OPENSSI-DEBIAN and DEBIAN should give you that. Make sure you do it > before importing new sources from debian. > > Hope this explains it. It is pretty complicated isn't it ? Now wonder > why viewcvs fails for our repository :) > > -aneesh > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Brian J. W. <Bri...@hp...> - 2006-12-21 19:54:44
|
Hi John, Be careful with the commit, import, tag, and admin commands. If in doubt, a good idea is to experiment with a copy of the repository. It's a lot less effort than cleaning up a mess in the real repository. Good luck, Brian John Hughes wrote: > Aneesh Kumar wrote: >> [ much useful info ] > Ok, thanks Aneesh. > > Lets see how badly I can screw this up :-) > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: John H. <john@Calva.COM> - 2006-12-22 09:11:03
|
Brian J. Watson wrote: > Hi John, > > Be careful with the commit, import, tag, and admin commands. If in > doubt, a good idea is to experiment with a copy of the repository. > It's a lot less effort than cleaning up a mess in the real repository. Oh, I'll be careful. If I wanted to make a copy of the repository how could I do that? As for the import, I see that I should be doing an "import -X" to avoid getting my stuff bunged into the trunk. Unfortunately Debian Sarge cvs doesn't have the "X" option so I'll try backporting the Etch version. |
From: Brian J. W. <Bri...@hp...> - 2006-12-22 19:51:50
|
John Hughes wrote: > Brian J. Watson wrote: >> Hi John, >> >> Be careful with the commit, import, tag, and admin commands. If in >> doubt, a good idea is to experiment with a copy of the repository. >> It's a lot less effort than cleaning up a mess in the real repository. > Oh, I'll be careful. > > If I wanted to make a copy of the repository how could I do that? Hi John, You can rsync a copy by following these SF instructions: https://sourceforge.net/docs/E04#rsync Regards, Brian |