Menu
▾
▴
naviserver-devel
|
From: Stephen D. <sd...@gm...> - 2008-04-17 10:46:03
|
nsdbi is a database driver interface for naviserver. It provides native bind variable support, transparent prepared queries and handle management, runtime configuration, statistics, and a few other things. There are drivers for postgres, mysql and sqlite. There's also a stub driver included for testing, fault injection etc. It relies on a few utility routines in naviserver, but it wouldn't be too hard to port those to aolserver, should anyone want to. Here's a snapshot of the man page: http://www.groks.org/nsdbi.n.html Tarballs: http://www.groks.org/nsdbi-0.1.tgz http://www.groks.org/nsdbipg-0.1.tgz http://www.groks.org/nsdbimy-0.1.tgz http://www.groks.org/nsdbilite-0.1.tgz Mercurial repositories: http://freehg.org/u/groks/nsdbi/ http://freehg.org/u/groks/nsdbipg/ http://freehg.org/u/groks/nsdbimy/ http://freehg.org/u/groks/nsdbilite/ |
|
From: Stephen D. <sd...@gm...> - 2008-05-02 19:06:49
|
(sorry for the delay) On Thu, Apr 17, 2008 at 3:49 PM, Vlad Seryakov <vl...@cr...> wrote: > This is very cool, > > Can you commit it into primary Naviserver CVS? Hmm, I hadn't thought about it much, I just wanted to get it off my hard drive. But now that you mention it, it would kind of suck to move it out of mercurial (and I'm not even sure there's a downward conversion tool...) Btw. some time ago I also converted the aolserver and naviserver histories to mercurial. I cleaned up the commits quite a lot so that logical changes appear in one changeset with comments in the right place in the right format, attributed to the right people etc. I collapsed about 30% of the commits IIRC. I did the same for naviserver then stuck it on to the end of the history of aolserver 4.0.10. So, there's now complete history going back 8 years which is browsable and annotatable. Check it out: http://freehg.org/u/groks/naviserver/ http://freehg.org/u/groks/aolserver/ I don't want to agitate for change too strongly, but maybe it's worth thinking about? http://www.selenic.com/mercurial/wiki/ |
|
From: Vlad S. <vl...@cr...> - 2008-05-02 19:50:46
|
Frankly, i would go from CVS to SVN/Mercurial/Git, whatever. I still think SF CVS sucks, so i would switch anytime if my voice will need to be counted:-))) The question i have, is freehg.org reliable and supposed to live long? On other hand SF is very popular and search engine favorite, not that popularity is my big concern though. Stephen Deasey wrote: > (sorry for the delay) > > > On Thu, Apr 17, 2008 at 3:49 PM, Vlad Seryakov <vl...@cr...> wrote: >> This is very cool, >> >> Can you commit it into primary Naviserver CVS? > > > Hmm, I hadn't thought about it much, I just wanted to get it off my > hard drive. But now that you mention it, it would kind of suck to move > it out of mercurial (and I'm not even sure there's a downward > conversion tool...) > > Btw. some time ago I also converted the aolserver and naviserver > histories to mercurial. I cleaned up the commits quite a lot so that > logical changes appear in one changeset with comments in the right > place in the right format, attributed to the right people etc. I > collapsed about 30% of the commits IIRC. > > I did the same for naviserver then stuck it on to the end of the > history of aolserver 4.0.10. So, there's now complete history going > back 8 years which is browsable and annotatable. Check it out: > > http://freehg.org/u/groks/naviserver/ > http://freehg.org/u/groks/aolserver/ > > > I don't want to agitate for change too strongly, but maybe it's worth > thinking about? > > > http://www.selenic.com/mercurial/wiki/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-03 13:01:58
|
On 02.05.2008, at 21:50, Vlad Seryakov wrote: > Frankly, i would go from CVS to SVN/Mercurial/Git, whatever. > I still think SF CVS sucks, so i would switch anytime if my voice will > need to be counted:-))) It seems as I'm the only one advocating continued use of CVS... And I have a simple reason: I do not see any benefit undertaking this (abandond-CVS) effort. What is to be gained? Or, perhaps, whar is that we are loosing by sticking to CVS? Zoran |
|
From: Vlad S. <vl...@cr...> - 2008-05-03 19:14:34
|
We've talked about this in the past and nobody could come up with very good reason, so i guess this time it is the same, i do not have big enough reason beside my not-liking Sf service. Vasiljevic Zoran wrote: > On 02.05.2008, at 21:50, Vlad Seryakov wrote: > >> Frankly, i would go from CVS to SVN/Mercurial/Git, whatever. >> I still think SF CVS sucks, so i would switch anytime if my voice will >> need to be counted:-))) > > It seems as I'm the only one advocating continued use of CVS... > And I have a simple reason: I do not see any benefit undertaking > this (abandond-CVS) effort. What is to be gained? Or, perhaps, > whar is that we are loosing by sticking to CVS? > > Zoran > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-04 15:37:51
|
On 03.05.2008, at 21:14, Vlad Seryakov wrote: > i do not have big > enough reason beside my not-liking Sf service. Just to be clear... SF supports both CVS and SVN. Is the SF in general that you do not like or is it the CVS especially? |
|
From: Vlad S. <vl...@cr...> - 2008-05-04 18:04:54
|
SF in general but CVS in particular, i remember offered to switch to SF SVN, but i could not find good enough reasons. With CVS i know that it does not handle directories, renaming, moving and i do not even try to do it, contacting SF everytime to cleanup CVS is not very convenient either. So, at least moving to SVN will make it much easier to control our repository, we can still stick with SF, i am not insisting. Vasiljevic Zoran wrote: > On 03.05.2008, at 21:14, Vlad Seryakov wrote: > >> i do not have big >> enough reason beside my not-liking Sf service. > > > Just to be clear... SF supports both CVS and SVN. > Is the SF in general that you do not like or is > it the CVS especially? > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > 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-05-05 23:56:41
|
On Sat, May 3, 2008 at 2:01 PM, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 02.05.2008, at 21:50, Vlad Seryakov wrote:
>
>> Frankly, i would go from CVS to SVN/Mercurial/Git, whatever.
>> I still think SF CVS sucks, so i would switch anytime if my voice will
>> need to be counted:-)))
>
> It seems as I'm the only one advocating continued use of CVS...
> And I have a simple reason: I do not see any benefit undertaking
> this (abandond-CVS) effort. What is to be gained? Or, perhaps,
> whar is that we are loosing by sticking to CVS?
I am too lazy to write that essay. You should try it out to see what
you're missing out on. Here's a starter:
mkdir ~/in ~/co
hg clone http://freehg.org/u/groks/naviserver/ ~/in/naviserver
hg clone ~/in/naviserver ~/co/ns-work
cd ~/co/ns-work
hg log -l 10
(I haven't updated the hg naviserver repo recently)
Try exporting some of your recent changes to the naviserver cvs repo
as patches, and then importing them to the hg repo.
Enable the mq Mercurial Queues extension:
# ~/.hgrc
[extensions]
mq=
Enable mq for your repo:
hg qinit
Import a few patches:
hg qimport ~/driver-send-recv.diff
hg qimport ~/nsjob-cancel.diff
hg qimport ~/nsjob-handle.diff
hg qimport ~/driver-send-recv-backout.diff
hg qimport ~/nsjob-errorcode.diff
hg qimport ~/nsjob-deadlock.diff
Check the repo:
hg log -l 10
hg outgoing
hg help outgoing
You could imagine that this is what you actually did -- you committed
a handful of patches locally before pushing them to the public repo.
Because you haven't typed 'hg push', you can change your mind.
For example, you could completely remove the send-recv patches:
hg qpop -a
hg qdel driver-send-recv.diff
hg qdel driver-send-recv-backout.diff
hg qpush -a
hg qseries
hg log -l 5
hg serve -v
I think the big advantage is that you it encourages you to write
better patches and it encourages better collaboration. There are
technical benefits as there were with subversion over cvs, such as
renames and atomic commits, but they're not day-to-day important.
It's that it encourages you to write high quality patches because
you're not worried about merging in your changes before some one else
touches the same files, you can break large changes down into a series
of well commented changesets -- a patchest, and you can edit your
patches into something coherent before you push to every one else.
Give it a try.
|
|
From: Stephen D. <sd...@gm...> - 2008-05-05 23:59:32
|
On Fri, May 2, 2008 at 8:50 PM, Vlad Seryakov <vl...@cr...> wrote: > Frankly, i would go from CVS to SVN/Mercurial/Git, whatever. > I still think SF CVS sucks, so i would switch anytime if my voice will > need to be counted:-))) > > The question i have, is freehg.org reliable and supposed to live long? > On other hand SF is very popular and search engine favorite, not that > popularity is my big concern though. freehg.org was just a convenient place to publish. I guess we would put the repos on the sourceforge web space. Mercurial can run as a cgi script front end to the repo for anonymous pulling and web browsing. Commiters would push via ssh. |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-08 12:10:35
|
On 06.05.2008, at 01:59, Stephen Deasey wrote: > freehg.org was just a convenient place to publish. I guess we would > put the repos on the sourceforge web space. Mercurial can run as a cgi > script front end to the repo for anonymous pulling and web browsing. > Commiters would push via ssh. This is all differential/integral computation for me. I would say: make whatever you think is OK and I wll just follow... Provided I can stick to my "commit/update" for the beginning, until I get comfortable with the brand new brave-21-century world... |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-07 09:11:57
|
On 06.05.2008, at 01:56, Stephen Deasey wrote:
> I am too lazy to write that essay. You should try it out to see what
> you're missing out on. Here's a starter:
That _was_ the essay! Thanks for going to such extent to
show me what SVN can do.
I recall watching a video on YouTube with Linus Thorvalds
http://www.youtube.com/watch?v=4XpnKHJAok8
where he takes both CVS and SVN under heavy barrage,
advocating for his GIT solution. As we are in the process
of considering a repository change, I thought everybody
should be at least informed about the other possibilities.
Personally, if you guys think we will benefit from such a
change, I will be the last one to oppose. It is just that
I do not have much time learning something new if it isn't
really bringing me immediate benefits (life is short and
internet is large).
Cheers
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2008-05-23 21:33:17
|
On Wed, May 7, 2008 at 10:11 AM, Vasiljevic Zoran <zv...@ar...> wrote: > > On 06.05.2008, at 01:56, Stephen Deasey wrote: > >> I am too lazy to write that essay. You should try it out to see what >> you're missing out on. Here's a starter: > > That _was_ the essay! Thanks for going to such extent to > show me what SVN can do. > > I recall watching a video on YouTube with Linus Thorvalds > > http://www.youtube.com/watch?v=4XpnKHJAok8 > > where he takes both CVS and SVN under heavy barrage, > advocating for his GIT solution. As we are in the process > of considering a repository change, I thought everybody > should be at least informed about the other possibilities. That's a great video. Here's another, a Google Tech Talk on Mercurial: http://video.google.com/videoplay?docid=-7724296011317502612 It's a while since I watched them both, but as I recall, they both talk more about the ideas behind dvcs, less than they do the particular commands. So it's an easy listen. Linus makes great points about things like git not needing commit permissions as cvs does and how this changes the dynamics of the project for the better -- no people on the inside vs. those on the outside. And things like clone and diff and commit being instantaneous, encouraging exploratory development. |
|
From: Ibrahim T. <it...@ar...> - 2008-05-07 10:03:36
|
FWIW, to let my paranoia out: I don't like SVN because it obscures and packs the whole repository into one big file, which IMHO overshadows all its benifits. I've been able in tha past to resolve the consequences of quite a few CVS bugs, due to the open structure of its repository. OTOH, if we're to continue using the services of SourceForge for the Naviserver project and Vlad, Stephen and Zoran who do most of the work are dissatisfied with CVS... I think at some point, there were contemplations to move the project to some local machines. Vlad was offering to host it, wasn't he? We (Zoran and I) at ARCHIWARE could offer a mirror too. In that case, we can consider going for other source control systems (GIT?) etc. and away from both CVS and SVN. Ibrahim Vasiljevic Zoran wrote: > On 06.05.2008, at 01:56, Stephen Deasey wrote: > >> I am too lazy to write that essay. You should try it out to see what >> you're missing out on. Here's a starter: > > That _was_ the essay! Thanks for going to such extent to > show me what SVN can do. > > I recall watching a video on YouTube with Linus Thorvalds > > http://www.youtube.com/watch?v=4XpnKHJAok8 > > where he takes both CVS and SVN under heavy barrage, > advocating for his GIT solution. As we are in the process > of considering a repository change, I thought everybody > should be at least informed about the other possibilities. > > Personally, if you guys think we will benefit from such a > change, I will be the last one to oppose. It is just that > I do not have much time learning something new if it isn't > really bringing me immediate benefits (life is short and > internet is large). > > Cheers > Zoran |
|
From: Stephen D. <sd...@gm...> - 2008-05-23 18:50:50
|
On Wed, May 7, 2008 at 11:03 AM, Ibrahim Tannir <it...@ar...> wrote: > FWIW, to let my paranoia out: > > I don't like SVN because it obscures and packs the whole > repository into one big file, which IMHO overshadows all its > benifits. > > I've been able in tha past to resolve the consequences of quite a > few CVS bugs, due to the open structure of its repository. > That's a good point. Mercurial and Git etc. are inherently better than cvs/svn because each time someone clones they get the full repo. A kind of built-in backup. That doesn't protect against cosmic rays, Murpheys Law. Perhaps a nice way to handle this is to use the ultimate text format as backup - patches. Mercurial has the nice feature that you can export commits as patches with a set of special headers which preserve the mercurial-specific info, such as the hashes, and the stuff that patches don't carry, such as the username, date etc. You could set up a trigger to dump a copy of each commit as a patch in some directory. I haven't tried, but I guess it wouldn't be too hard. You can simulate it by importing the whole repo into a patch queue: hg clone ~/in/naviserver ~/ns-test cd test hg qinit hg qimport -r : The ':' is python-like slice notation for a range of commits, which in this case says 'everything'. You could also say -r 0:tip. The patches are kept in numbered order in: ~/ns-test/.hg/patches Another of the nice properties of mercurial is the content hashing, which like git uses sha1 to hash the content of each changeset, including the metadata. Mercurial also mixes in the hash of the parent(s) changesets. So, when you reapply all the patches to reconsitute the repo, and corruption will be noticed because the hashes won't match. This would be a nice little project for someone... |
|
From: Gustaf N. <ne...@wu...> - 2008-05-07 10:24:30
|
Let me point out another nice feature of git: git provides server-support to behave to clients like a cvs and/or svn server. This means, one can access the git repository from cvs or svn (or git) clients. Not sure if this is an issue, but a user who does not want to learn new commands can contiune to use the CVS interface. I personally like git for its speed and simplicity to setup and usage. Git has certain ideosyncharies (e.g. does not like empty directories), and the downside is that if the full feature set of a more distributed scm is used, things become quite complex, at least for a casual user. just my 2cent -gustaf Ibrahim Tannir schrieb: > FWIW, to let my paranoia out: > > I don't like SVN because it obscures and packs the whole > repository into one big file, which IMHO overshadows all its > benifits. > > I've been able in tha past to resolve the consequences of quite a > few CVS bugs, due to the open structure of its repository. > > OTOH, if we're to continue using the services of SourceForge for > the Naviserver project and Vlad, Stephen and Zoran who do most of > the work are dissatisfied with CVS... > > I think at some point, there were contemplations to move the > project to some local machines. Vlad was offering to host it, > wasn't he? We (Zoran and I) at ARCHIWARE could offer a mirror > too. In that case, we can consider going for other source control > systems (GIT?) etc. and away from both CVS and SVN. > > Ibrahim > |
|
From: Stephen D. <sd...@gm...> - 2008-05-23 19:07:48
|
On Wed, May 7, 2008 at 11:24 AM, Gustaf Neumann <ne...@wu...> wrote: > > Let me point out another nice feature of git: > git provides server-support to behave to clients like a > cvs and/or svn server. This means, one can access the git > repository from cvs or svn (or git) clients. Not sure > if this is an issue, but a user who does not want to > learn new commands can contiune to use the CVS interface. I'm not sure this is actually useful. You can't really commit from cvs or svn, and a straight checkout is actually easier in hg and git than cvs, which requires you to specify a user even if it's just anon, and they often show this in two stages. For those who don't want to install any extra tools I've enabled the tarball feature. You can grab a tarball of any revision of any project straight from the web interface. > I personally like git for its speed and simplicity to setup and > usage. Git has certain ideosyncharies (e.g. does not like > empty directories), and the downside is that if the full > feature set of a more distributed scm is used, things become > quite complex, at least for a casual user. Git is very nice. But it is considerably harder to use than hg. Even for someone like Zoran, who is quite capable, but is too busy to faff around with something like this, I think that would be a barrier. The main thing for me re hg and git is that you can't go wrong with either of them, where as cvs and svn have too much baggage these days and most of the other systems have serious problems some where. Bazaar is probably a solid 3rd -- a Dr. Pepper to the Coke and Pepsi of git hg... :-) |
|
From: Vlad S. <vl...@cr...> - 2008-05-07 17:56:43
|
One benefit i can see is not immediate and obvious but having more flexible source control system may attract or make it easy to handle access to more developers, easy to revert unneeded changes, as Stephan pointed, better patch control and changsets. Yes, it will require some learning but not that much, still this is just source control system, using it in the-CVS-mode, as commit/update/diff, will be possible with any tool. Oh, one more, it is 21st century, CVS is not part of that:-))) Vasiljevic Zoran wrote: > On 06.05.2008, at 01:56, Stephen Deasey wrote: > >> I am too lazy to write that essay. You should try it out to see what >> you're missing out on. Here's a starter: > > That _was_ the essay! Thanks for going to such extent to > show me what SVN can do. > > I recall watching a video on YouTube with Linus Thorvalds > > http://www.youtube.com/watch?v=4XpnKHJAok8 > > where he takes both CVS and SVN under heavy barrage, > advocating for his GIT solution. As we are in the process > of considering a repository change, I thought everybody > should be at least informed about the other possibilities. > > Personally, if you guys think we will benefit from such a > change, I will be the last one to oppose. It is just that > I do not have much time learning something new if it isn't > really bringing me immediate benefits (life is short and > internet is large). > > Cheers > Zoran > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-07 19:22:41
|
On 07.05.2008, at 19:56, Vlad Seryakov wrote: > system may attract or make it easy to handle > access to more developers I doubt that. You could do that only if you make the server to be (one of the platforms) for some Web toolkits like ACS or Ruby on Rails etc pp. And, optionaly, if you make it "simple" and fast to deploy, like being a loadable Tcl extension. Or a Ruby extension (I'm brainstorming). |
|
From: Stephen D. <sd...@gm...> - 2008-05-23 19:35:03
|
On Wed, May 7, 2008 at 6:56 PM, Vlad Seryakov <vl...@cr...> wrote: > One benefit i can see is not immediate and obvious but having more > flexible source control system may attract or make it easy to handle > access to more developers, easy to revert unneeded changes, as Stephan > pointed, better patch control and changsets. > > Yes, it will require some learning but not that much, still this is just > source control system, using it in the-CVS-mode, as commit/update/diff, > will be possible with any tool. > Yeah, for this particular project then a new version control system is not going to bring new developers stampeding through the door. But there is some potentially nice usability benefits for newbies. A couple of times recently on the aolserver list there should have been some patches flowing but instead either whole files or tarballs have been posted, making it extremely difficult to figure out whats been changed, and making it unlikely that the changes will be incorporated into cvs. The mechanics of doing it right aren't hard per-se, but it can be non obvious and sometimes it's a pain. Obviously there are other problems with aolserver development, but if there was a culture of passing patches back and forth it would make up for a lot. I think in general we've just scratched the surface of how to work with dvcs'. A lot of focus has been put on some of the new technical abilities, just as svn was better because of atomic commits, renames etc. But the new systems have a lot more headroom for new ways to work. It's interesting to me, that after ~ 3 years use of git for kernel development they're even now having discussions about whether or not you should rebase if you're a maintainer (pull and rebase other peoples patches). You shouldn't, apparently, and the way it was explained makes sense (saw this on kerneltrap.org I think, if you're interested). It will be cool to see how open source development is done in a couple of years when we figure this all out... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X