From: Stephen D. <sd...@gm...> - 2008-05-23 18:31:25
|
I updated the naviserver mercurial repo with the latest changes from cvs put it on sourceforge: http://naviserver.sourceforge.net/hg/ To check it out: hg clone http://naviserver.sourceforge.net/hg/naviserver ~/in/naviserver-hg Or, if you've already cloned from the freehg.org repo, you can simply update with the differences: hg -R ~/in/navserver-hg pull -u The -u at the end means 'and update the working directory'. pull and update are 2 separate things. The -R saves you from CD'ing into the repo directory. If you are updating instead of cloning, you might want to change the default pull location in the repo config file: ~/in/naviserver-hg/.hg/hgrc [paths] default = http://naviserver.sourceforge.net/hg/naviserver Now you don't have to specify where to pull from each time. cd into the repo directory and 'hg pull -u'. Same for other commands which work with two repos: incoming, outgoing etc. I guess that's how most people would grab a copy of the latest source. For people who expect to commit to the public repo themselves you might want to clone via ssh. A couple of prerequisites: Add something like the following to your ~/.ssh/config file: Host sf shell.sf.net Hostname shell.sf.net User yoursfusername log into sf and do the following: ssh sf ln -s /home/groups/n/na/naviserver ~/ns echo "source /home/groups/n/na/naviserver/bashc" >> ~/.bashrc bashrc just sets the umask correctly and adds the 'hg' command to the PATH. Now you can clone via ssh: hg clone ssh://sf/ns/hg/naviserver ~/in/naviserver-hg That's also where you push to make your commits public. hg clone ~/in/naviserver-hg ~/ns-work cd ~/work ... hack hack hack ... hg commit hg push ssh://sf/ns/hg/naviserver For people who don't have direct commit access, and with mercurial that's really no disadvantage, perhaps a good way to work is to use the 'patchbomb' extension. Add the following to your ~/.hgrc file: [extensions] patchbomb= [email] from = Your Name <you@wherever> [smtp] host = smtp.gmail.com port = 587 tls = 1 username = you@wherever password = **** (or whatever) btw. you'll also want to make sure that the following is present -- it's what your name appears as in the commit message: [ui] username = Your Name <you@wherever> Now, to publish your last commit (the tip, aka HEAD) you could do: hg email -r tip --to nav...@li... ('hg help email' for more) The patch is created as an attachment such that it can exactly reproduce the commit when imported to another repo, including the committer name, date etc., so full credit is always given. At this point some one with commit access would import the patch, check it, and if OK push it: hg import ~/saved-email hg push Commit Messages: Format them like an email. A single like subject of about ~70 chars, followed by a blank like, followed by the body, word wrapped to ~80 chars. Keyword stuff the subject so that folks can get the gist of it by skimming. Prefix with a module name such as nsperm: if you think it makes sense. Say 'Add ...' instead of 'Added ...'. The commit messages should be working, and so is cia.vc. Here's an example: http://sourceforge.net/mailarchive/message.php?msg_id=hg.1883a10a6e0c.1210791169.-2015825136%40sc8-pr-shella-b.sourceforge.net Does this all look OK? |
From: Vlad S. <vl...@cr...> - 2008-05-23 18:41:36
|
Does that mean i have to use either one, CVS or HG, not both at the same time? What i am asking, we still have 2 repos, will it work if commits are coming to both of them? Stephen Deasey wrote: > I updated the naviserver mercurial repo with the latest changes from > cvs put it on sourceforge: > > http://naviserver.sourceforge.net/hg/ > > > To check it out: > > hg clone http://naviserver.sourceforge.net/hg/naviserver ~/in/naviserver-hg > > Or, if you've already cloned from the freehg.org repo, you can simply > update with the differences: > > hg -R ~/in/navserver-hg pull -u > > The -u at the end means 'and update the working directory'. pull and > update are 2 separate things. > The -R saves you from CD'ing into the repo directory. > > If you are updating instead of cloning, you might want to change the > default pull location in the repo config file: > > ~/in/naviserver-hg/.hg/hgrc > > [paths] > default = http://naviserver.sourceforge.net/hg/naviserver > > Now you don't have to specify where to pull from each time. cd into > the repo directory and 'hg pull -u'. Same for other commands which > work with two repos: incoming, outgoing etc. > > > I guess that's how most people would grab a copy of the latest source. > For people who expect to commit to the public repo themselves you > might want to clone via ssh. A couple of prerequisites: > > Add something like the following to your ~/.ssh/config file: > > Host sf shell.sf.net > Hostname shell.sf.net > User yoursfusername > > log into sf and do the following: > > ssh sf > ln -s /home/groups/n/na/naviserver ~/ns > echo "source /home/groups/n/na/naviserver/bashc" >> ~/.bashrc > > bashrc just sets the umask correctly and adds the 'hg' command to the PATH. > > Now you can clone via ssh: > > hg clone ssh://sf/ns/hg/naviserver ~/in/naviserver-hg > > That's also where you push to make your commits public. > > hg clone ~/in/naviserver-hg ~/ns-work > cd ~/work > ... hack hack hack ... > hg commit > hg push ssh://sf/ns/hg/naviserver > > > For people who don't have direct commit access, and with mercurial > that's really no disadvantage, perhaps a good way to work is to use > the 'patchbomb' extension. Add the following to your ~/.hgrc file: > > [extensions] > patchbomb= > > [email] > from = Your Name <you@wherever> > > [smtp] > host = smtp.gmail.com > port = 587 > tls = 1 > username = you@wherever > password = **** > > (or whatever) > > btw. you'll also want to make sure that the following is present -- > it's what your name appears as in the commit message: > > [ui] > username = Your Name <you@wherever> > > > Now, to publish your last commit (the tip, aka HEAD) you could do: > > hg email -r tip --to nav...@li... > > ('hg help email' for more) > > The patch is created as an attachment such that it can exactly > reproduce the commit when imported to another repo, including the > committer name, date etc., so full credit is always given. At this > point some one with commit access would import the patch, check it, > and if OK push it: > > hg import ~/saved-email > hg push > > > Commit Messages: > > Format them like an email. A single like subject of about ~70 chars, > followed by a blank like, followed by the body, word wrapped to ~80 > chars. Keyword stuff the subject so that folks can get the gist of it > by skimming. Prefix with a module name such as nsperm: if you think it > makes sense. Say 'Add ...' instead of 'Added ...'. > > > > The commit messages should be working, and so is cia.vc. Here's an example: > > http://sourceforge.net/mailarchive/message.php?msg_id=hg.1883a10a6e0c.1210791169.-2015825136%40sc8-pr-shella-b.sourceforge.net > > > Does this all look OK? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Stephen D. <sd...@gm...> - 2008-05-23 19:40:48
|
On Fri, May 23, 2008 at 7:39 PM, Vlad Seryakov <vl...@cr...> wrote: > Does that mean i have to use either one, CVS or HG, not both at the same > time? > What i am asking, we still have 2 repos, will it work if commits are > coming to both of them? No, we should use one or the other. Or, we should treat what's in the hg repos now as a demo/test and plan to redo them later. You could commit your recent change to the hg repo and then they will be in synch again, and we can decide what to do. You can be the guinea pig :-) btw. I deleted the ChangeLog in the hg repo. The commit log messages should be enough. |
From: Vlad S. <vl...@cr...> - 2008-05-23 19:47:27
|
I am personally ready to switch right away, i use hg for xine-lib for a long time already, in readonly mode but it did not require much learning to use it. More questions, is hg repo hosted by SF? Is it Sf service or you just run additional hg server there? Stephen Deasey wrote: > On Fri, May 23, 2008 at 7:39 PM, Vlad Seryakov <vl...@cr...> wrote: >> Does that mean i have to use either one, CVS or HG, not both at the same >> time? >> What i am asking, we still have 2 repos, will it work if commits are >> coming to both of them? > > > No, we should use one or the other. > > Or, we should treat what's in the hg repos now as a demo/test and plan > to redo them later. > > > > You could commit your recent change to the hg repo and then they will > be in synch again, and we can decide what to do. You can be the guinea > pig :-) > > btw. I deleted the ChangeLog in the hg repo. The commit log messages > should be enough. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Stephen D. <sd...@gm...> - 2008-05-23 20:42:52
|
On Fri, May 23, 2008 at 8:45 PM, Vlad Seryakov <vl...@cr...> wrote: > I am personally ready to switch right away, i use hg for xine-lib for a > long time already, in readonly mode but it did not require much learning > to use it. > > More questions, is hg repo hosted by SF? Is it Sf service or you just > run additional hg server there? I basically followed this recipe: http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge Although I used mercurial-1.0 (installed into /home/groups/n/na/naviserver/local/mercurial-1.0) All the repos live in /home/groups/n/na/naviserver/hg Mercurial comes with cgi-scripts to publish the repos, that's what you see when you go to: http://naviserver.sourceforge.net/hg/ (See: /home/groups/n/na/naviserver/cgi-bin) (And btw. you can get the same view on your own machine by typing 'hg serve', built-in web server). So, the repos in $SF/hg are basically identical to what you end up with on your own machine when you clone. The only difference is that I modified the per-repo hgrc file to add the hooks for commit messages and a couple of other small things. I guess I should make clear, the naviserver repo, and each of the module repos would in fact be individual repos. So to convert the other modules from cvs, you'd run 'hg convert' (which you have to enable first, it's an extension shipped with mercurial). And then you'd clean it up a little, make sure the commit messages follow the mercurial style etc. And then you'd clone it up there: hg clone ./nsexample ssh://sf/ns/hg/nsexample And then you would ssh into sf and copy the hgrc from an existing repo into the new one: ssh sf cd ~/ns/hg cp naviserver/.hg/hgrc nsexample/.hg/hgrc vi nsexample It should show up in the web interface automatically. You only need to edit the top of the file to change the display name, basically just this: [web] description = Programmable Web Server [cia] module = naviserver You could also edit 'contact' if you like. It's just for display on the web interface. That should be it. We can go into more details about how to convert modules from cvs later, but shout out if you're keen to get started. |
From: Vlad S. <vl...@cr...> - 2008-05-23 20:52:26
|
Another question: why to keep every module in separate repo? will it be easier to have them under one root? Stephen Deasey wrote: > On Fri, May 23, 2008 at 8:45 PM, Vlad Seryakov <vl...@cr...> wrote: >> I am personally ready to switch right away, i use hg for xine-lib for a >> long time already, in readonly mode but it did not require much learning >> to use it. >> >> More questions, is hg repo hosted by SF? Is it Sf service or you just >> run additional hg server there? > > > I basically followed this recipe: > > http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge > > Although I used mercurial-1.0 (installed into > /home/groups/n/na/naviserver/local/mercurial-1.0) > > All the repos live in /home/groups/n/na/naviserver/hg > > Mercurial comes with cgi-scripts to publish the repos, that's what you > see when you go to: > > http://naviserver.sourceforge.net/hg/ > > (See: /home/groups/n/na/naviserver/cgi-bin) > > (And btw. you can get the same view on your own machine by typing 'hg > serve', built-in web server). > > > So, the repos in $SF/hg are basically identical to what you end up > with on your own machine when you clone. The only difference is that I > modified the per-repo hgrc file to add the hooks for commit messages > and a couple of other small things. > > I guess I should make clear, the naviserver repo, and each of the > module repos would in fact be individual repos. > > > So to convert the other modules from cvs, you'd run 'hg convert' > (which you have to enable first, it's an extension shipped with > mercurial). And then you'd clean it up a little, make sure the commit > messages follow the mercurial style etc. And then you'd clone it up > there: > > hg clone ./nsexample ssh://sf/ns/hg/nsexample > > And then you would ssh into sf and copy the hgrc from an existing repo > into the new one: > > ssh sf > cd ~/ns/hg > cp naviserver/.hg/hgrc nsexample/.hg/hgrc > vi nsexample > > It should show up in the web interface automatically. You only need > to edit the top of the file to change the display name, basically just > this: > > [web] > description = Programmable Web Server > > [cia] > module = naviserver > > You could also edit 'contact' if you like. It's just for display on > the web interface. > > > That should be it. We can go into more details about how to convert > modules from cvs later, but shout out if you're keen to get started. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Stephen D. <sd...@gm...> - 2008-05-23 21:13:30
|
On Fri, May 23, 2008 at 9:50 PM, Vlad Seryakov <vl...@cr...> wrote: > Another question: why to keep every module in separate repo? > will it be easier to have them under one root? No, they need to be separate repos. The reason is that unlike cvs hg is changeset based. There is one commit message that goes with the changes to a collection of files. They go together, like a transaction in a db. When you do a 'hg log' you get the commit message, user, date etc. for each changeset. If we put all the modules into one repo then it would be like have just one ChangeLog for everything, with all message mixed together. Also, things like tags are repo wide, and you don't really want to tag nsdbi with naviserver-4.99.2, and vice-versa. There is an extension call 'forrest' which is something like repos within repos. I don't know if it's needed though. To keep updated, you could just stick something like the following in cron: for repo in ~/in/ns/*-hg; do hg -R $repo pull done We could publish a shell script with a list of all modules, to bootstrap for those who want a copy of everything. Also, slightly related, I think we want to follow a repo-as-branch model. So no branches within repos. It's simpler. |
From: Vlad S. <vl...@cr...> - 2008-06-02 01:13:21
|
I decided to try, followed all the instructions. First impression is very positive, it was easy. I commited my latest changes into hg, so now both repos are in sync. I will try to maintain both for a while and see how it goes and will import all the modules one by one. Stephen Deasey wrote: > I updated the naviserver mercurial repo with the latest changes from > cvs put it on sourceforge: > > http://naviserver.sourceforge.net/hg/ > > > To check it out: > > hg clone http://naviserver.sourceforge.net/hg/naviserver ~/in/naviserver-hg > > Or, if you've already cloned from the freehg.org repo, you can simply > update with the differences: > > hg -R ~/in/navserver-hg pull -u > > The -u at the end means 'and update the working directory'. pull and > update are 2 separate things. > The -R saves you from CD'ing into the repo directory. > > If you are updating instead of cloning, you might want to change the > default pull location in the repo config file: > > ~/in/naviserver-hg/.hg/hgrc > > [paths] > default = http://naviserver.sourceforge.net/hg/naviserver > > Now you don't have to specify where to pull from each time. cd into > the repo directory and 'hg pull -u'. Same for other commands which > work with two repos: incoming, outgoing etc. > > > I guess that's how most people would grab a copy of the latest source. > For people who expect to commit to the public repo themselves you > might want to clone via ssh. A couple of prerequisites: > > Add something like the following to your ~/.ssh/config file: > > Host sf shell.sf.net > Hostname shell.sf.net > User yoursfusername > > log into sf and do the following: > > ssh sf > ln -s /home/groups/n/na/naviserver ~/ns > echo "source /home/groups/n/na/naviserver/bashc" >> ~/.bashrc > > bashrc just sets the umask correctly and adds the 'hg' command to the PATH. > > Now you can clone via ssh: > > hg clone ssh://sf/ns/hg/naviserver ~/in/naviserver-hg > > That's also where you push to make your commits public. > > hg clone ~/in/naviserver-hg ~/ns-work > cd ~/work > ... hack hack hack ... > hg commit > hg push ssh://sf/ns/hg/naviserver > > > For people who don't have direct commit access, and with mercurial > that's really no disadvantage, perhaps a good way to work is to use > the 'patchbomb' extension. Add the following to your ~/.hgrc file: > > [extensions] > patchbomb= > > [email] > from = Your Name <you@wherever> > > [smtp] > host = smtp.gmail.com > port = 587 > tls = 1 > username = you@wherever > password = **** > > (or whatever) > > btw. you'll also want to make sure that the following is present -- > it's what your name appears as in the commit message: > > [ui] > username = Your Name <you@wherever> > > > Now, to publish your last commit (the tip, aka HEAD) you could do: > > hg email -r tip --to nav...@li... > > ('hg help email' for more) > > The patch is created as an attachment such that it can exactly > reproduce the commit when imported to another repo, including the > committer name, date etc., so full credit is always given. At this > point some one with commit access would import the patch, check it, > and if OK push it: > > hg import ~/saved-email > hg push > > > Commit Messages: > > Format them like an email. A single like subject of about ~70 chars, > followed by a blank like, followed by the body, word wrapped to ~80 > chars. Keyword stuff the subject so that folks can get the gist of it > by skimming. Prefix with a module name such as nsperm: if you think it > makes sense. Say 'Add ...' instead of 'Added ...'. > > > > The commit messages should be working, and so is cia.vc. Here's an example: > > http://sourceforge.net/mailarchive/message.php?msg_id=hg.1883a10a6e0c.1210791169.-2015825136%40sc8-pr-shella-b.sourceforge.net > > > Does this all look OK? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov vl...@cr... http://www.crystalballinc.com/vlad/ |
From: Stephen D. <sd...@gm...> - 2008-06-02 17:18:56
|
On Mon, Jun 2, 2008 at 2:08 AM, Vlad Seryakov <vl...@cr...> wrote: > I decided to try, followed all the instructions. > First impression is very positive, it was easy. I commited my latest > changes into hg, so now both repos are in sync. > I will try to maintain both for a while and see how it goes and will > import all the modules one by one. Groovy. Looks like the commit email got lost somewhere :-/ I thought I had that sorted... Also, double-check your ui.username in ~/.hgrc [ui] username = Vlad Seryakov <vlad@...> http://naviserver.sourceforge.net/hg/naviserver/ If you're going to try a conversion, you might want to do something like rsync the sf cvs repo to your local machine, for speed. The hg convert command wants to be pointed at a checkout, but it reaches back into the repo for history. rsync -avz --delete \ rsync://naviserver.cvs.sourceforge.net/cvsroot/naviserver/ \ ~/in/naviserver-CVSROOT cvs -d ~/in/naviserver-CVSROOT co -d ~/co/nsmemcache-HEAD modules/nsmemcache echo "seryakov=Vlad Seryakov <vlad@crystal...>" > ~/authors hg convert -A ~/authors --config config.hg.usebranchnames=0 --config config.hg.clonebranches=1 \ ~/co/nsmemcache-HEAD ~/co/nsmemcache cd ~/co/nsmemcache/default hg qinit hg qimport -r : hg up hg qpop -a ls # all gone... All that's left is to clean up some of the formatting of the commit messages. Just edit the patch and then push it. (there's only 8 revisions to nsmemcache). less .hg/patches/1.diff # looks good hg qpush vi .hg/patches/2.diff hg qpush You will need to add other people to the ~/authors file if they've touched the module you're converting. When your done: hg clone ~/co/nsmemcache/default ~/co/nsmemcache-hg rm -rf ~/co/nsmemcache hg clone ~/co/nsmemcache-hg ssh://sf/ns/hg/nsmemcache |