naviserver-devel — Developer discussion

Re: [naviserver-devel] hosting java-script server-side?

[Vlad S. <vl...@cr...>]

yes, all docs are in doctools under doc/src and there is make build-doc
command that will generate .html and .n files under doc/html and doc/man

make install will install manpages and html files in the installation 
directory so for the first access to newly installed server 
documentation will be available

Also, when do you plan to release 5.0?

Zoran Vasiljevic wrote:
> On 27.09.2006, at 16:47, Vlad Seryakov wrote:
> 
>> It would be good to have documentation ready for the 5.0 release, at
>> least all commands needs to be somewhat documented.
> 
> Correct. As all (most) is now in CVS and in doctools...
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] hosting java-script server-side?

[Zoran V. <zv...@ar...>]

On 27.09.2006, at 16:47, Vlad Seryakov wrote:

> It would be good to have documentation ready for the 5.0 release, at
> least all commands needs to be somewhat documented.

Correct. As all (most) is now in CVS and in doctools...

Re: [naviserver-devel] hosting java-script server-side?

[Vlad S. <vl...@cr...>]

It would be good to have documentation ready for the 5.0 release, at 
least all commands needs to be somewhat documented.

Zoran Vasiljevic wrote:
> On 17.09.2006, at 19:37, Zoran Vasiljevic wrote:
> 
>> I just wanted to hear what people would think about this.
> 
> The response(s) so far were almost unisono: NO.
> Summary (rough):  We like Tcl and we are happy with
> C/Tcl server as-is now. There is no need for any
> alternative page-construction language (PHP, JS,
> whatever) because what we have is good (enough)
> and its fairly easy to learn Tcl anyway, so why
> bother with anyhing else?
> 
> It is good to know where are we when thinking about
> evolvement of the server code for the next few years.
> 
> As the documentation effort (Vlad, Bernd, you are champs!)
> is materializing, we will soon be able to release our
> long awaited 5.0 release, as planned some time ago.
> This is the time to start to think about all the cool
> things we always wanted to do but never had time for or
> were afraid to ask :-)
> 
> What I wanted to do before 5.0 is to integrate the ns_proxy
> with ns_job (and junk the former). If there are any special
> wishes (which we can slip into before the 5.0) please use
> RFE section at SF.
> 
> Cheers
> zoran
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] hosting java-script server-side?

[Zoran V. <zv...@ar...>]

On 17.09.2006, at 19:37, Zoran Vasiljevic wrote:

> I just wanted to hear what people would think about this.

The response(s) so far were almost unisono: NO.
Summary (rough):  We like Tcl and we are happy with
C/Tcl server as-is now. There is no need for any
alternative page-construction language (PHP, JS,
whatever) because what we have is good (enough)
and its fairly easy to learn Tcl anyway, so why
bother with anyhing else?

It is good to know where are we when thinking about
evolvement of the server code for the next few years.

As the documentation effort (Vlad, Bernd, you are champs!)
is materializing, we will soon be able to release our
long awaited 5.0 release, as planned some time ago.
This is the time to start to think about all the cool
things we always wanted to do but never had time for or
were afraid to ask :-)

What I wanted to do before 5.0 is to integrate the ns_proxy
with ns_job (and junk the former). If there are any special
wishes (which we can slip into before the 5.0) please use
RFE section at SF.

Cheers
zoran

Re: [naviserver-devel] brave new world

[Zoran V. <zv...@ar...>]

On 26.09.2006, at 00:26, Mike wrote:

> I highly recommend a download and read-through of lighttpd sources.
> They have a very simple abstraction that handles the available
> interfaces (kqueue, poll, and friends).

Indeed. They use their own abstraction of fdevents which
translates to either pool, port, devpool, kqueue or
whatever is available on the target system.

This is a good starting point for our own endeavours.
Thanks for the tip!

Re: [naviserver-devel] brave new world

[Mike <nee...@gm...>]

On 9/25/06, Zoran Vasiljevic <zv...@ar...> wrote:
> Unix is not Unix as I see...
>
> Please note this (interesting) document:
>
>    http://developers.sun.com/solaris/articles/event_completion.html
>
> Mostly interesting, as there is now a very powerful and scalable
> notification interface on both Solaris and Mac OSX (aka BSD)
> Unixes. Windows has it as well, with Linux hanging pretty much
> behind (unfortunately).
>
> I wonder if we should start making ifdefs or wrappers to be able
> to benefit from the corresponding event notification interface
> available on the current platform.
>
> Mainly this would affect poll() usage in the driver thread
> but can also be used all arround the code where we have to
> wait for multiple "things" to happen.
>
> Does anybody have something to comment about that?
>
> Ah yes.., why "brawe new world"? Because Unix OS is diverging
> and OS vendors are adding new (incompatible) functionality
> on a monthly basis. I wonder how this will all look in 10
> years in future...

I highly recommend a download and read-through of lighttpd sources.
They have a very simple abstraction that handles the available
interfaces (kqueue, poll, and friends).  Since it's also a web server,
I imagine the API can be adopted (that, and the fact that the code is
very well written and clean make it an ideal candidate to examine, in
my opinion).

Re: [naviserver-devel] brave new world

[Zoran V. <zv...@ar...>]

On 25.09.2006, at 21:42, Vlad Seryakov wrote:

> We use  Linux only, so it will not affect us but if using new API will
> change the way the program works, how it will be possible to support
> Solaris, Linux, Windows and MaxOSX at the same time?

The same way as it is possible to maintain Windows code
in parallel... i.e. by defining wrapping procedures and
ifdef's. This is obviously something that we will have
to do more and more in the future.

Re: [naviserver-devel] brave new world

[Vlad S. <vl...@cr...>]

We use  Linux only, so it will not affect us but if using new API will 
change the way the program works, how it will be possible to support 
Solaris, Linux, Windows and MaxOSX at the same time?

Zoran Vasiljevic wrote:
> Unix is not Unix as I see...
> 
> Please note this (interesting) document:
> 
>    http://developers.sun.com/solaris/articles/event_completion.html
> 
> Mostly interesting, as there is now a very powerful and scalable
> notification interface on both Solaris and Mac OSX (aka BSD)
> Unixes. Windows has it as well, with Linux hanging pretty much
> behind (unfortunately).
> 
> I wonder if we should start making ifdefs or wrappers to be able
> to benefit from the corresponding event notification interface
> available on the current platform.
> 
> Mainly this would affect poll() usage in the driver thread
> but can also be used all arround the code where we have to
> wait for multiple "things" to happen.
> 
> Does anybody have something to comment about that?
> 
> Ah yes.., why "brawe new world"? Because Unix OS is diverging
> and OS vendors are adding new (incompatible) functionality
> on a monthly basis. I wonder how this will all look in 10
> years in future...
> 
> Cheers
> Zoran 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] brave new world

[Zoran V. <zv...@ar...>]

Unix is not Unix as I see...

Please note this (interesting) document:

   http://developers.sun.com/solaris/articles/event_completion.html

Mostly interesting, as there is now a very powerful and scalable
notification interface on both Solaris and Mac OSX (aka BSD)
Unixes. Windows has it as well, with Linux hanging pretty much
behind (unfortunately).

I wonder if we should start making ifdefs or wrappers to be able
to benefit from the corresponding event notification interface
available on the current platform.

Mainly this would affect poll() usage in the driver thread
but can also be used all arround the code where we have to
wait for multiple "things" to happen.

Does anybody have something to comment about that?

Ah yes.., why "brawe new world"? Because Unix OS is diverging
and OS vendors are adding new (incompatible) functionality
on a monthly basis. I wonder how this will all look in 10
years in future...

Cheers
Zoran 

Re: [naviserver-devel] Tcl object handling

[Zoran V. <zv...@ar...>]

On 25.09.2006, at 11:40, Gustaf Neumann wrote:

> When doing some tests, it shows that the version with
> Tcl_NewIntObj() is measurable slower than the version with the
> reused result object (no wonder) but as well slower than the
> version with Tcl_ResetResult().
>
> For the following test, i measured the total time of calling
> a simple xotcl command (... info superclass <someclass>), including
> all xotcl overhead. The xotcl command was called 100.000 times, the  
> test
> was performed 100 times to get useful granularity from the timer.
>   puts [time {time $cmd 100000} 100]
>
>
> Tcl_SetIntObj(Tcl_GetObjResult(in), 1);    168524,55    100,00%
> Tcl_SetObjResult(in, Tcl_NewIntObj(1))    186699,12    110,78%
> Reset & Tcl_SetIntObj(Tcl_GetObjResult(in), 1);    178237,24     
> 105,76%
>
> The timings are from a PowerPC G5 with 2.1 GHz.
> This shows that the runtime of the xotcl command is 10% slower with
> NewIntObj() and 5% slower with ResetResult() than the runtime
> of the command with setting the result obj. I get similar
> timings for other commands like "... isobject ..." as well.
>
> The differences are bigger than expected. Certainly, for some
> applications that might not matter....

hmhmhmhm... this is most interesting. I would have to see how
and Tcl_ResetResult followed by Tcl_SetWhatever can be slower
than Tcl_SetObjResult. I would bet two are the same (have to do
the same work, rather, Tcl_ResetResult must do even more).

This is most interesting...

Re: [naviserver-devel] Tcl object handling

[Gustaf N. <ne...@wu...>]

Hi,

Maybe someon is interested in some findings about the problem
with

   Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);

i just workd through the xotcl c code, and found indeed a potential
source for the problem (in the non-frequently used
XOTclOIsMixinMethod() call) and fixed it.

It is my understanding that the problem with the shared result object 
happens
only when some c-code sets the result with an shared object somewhere after
the start of the command (e.g. doing an eval). Simple commands
are still safe. When doing some tests, it shows that the version with
Tcl_NewIntObj() is measurable slower than the version with the
reused result object (no wonder) but as well slower than the
version with Tcl_ResetResult().

For the following test, i measured the total time of calling
a simple xotcl command (... info superclass <someclass>), including
all xotcl overhead. The xotcl command was called 100.000 times, the test
was performed 100 times to get useful granularity from the timer.
  puts [time {time $cmd 100000} 100]


Tcl_SetIntObj(Tcl_GetObjResult(in), 1);    168524,55    100,00%
Tcl_SetObjResult(in, Tcl_NewIntObj(1))    186699,12    110,78%
Reset & Tcl_SetIntObj(Tcl_GetObjResult(in), 1);    178237,24    105,76%

The timings are from a PowerPC G5 with 2.1 GHz.
This shows that the runtime of the xotcl command is 10% slower with
NewIntObj() and 5% slower with ResetResult() than the runtime
of the command with setting the result obj. I get similar
timings for other commands like "... isobject ..." as well.

The differences are bigger than expected. Certainly, for some
applications that might not matter....

-gustaf neumann

[naviserver-devel] Documentation status

[Vlad S. <vl...@cr...>]

Here it is the doctools generated html files from source manpages.

http://www.crystalballinc.com/vlad/nsdocs/toc.html

doctool does all auto-referencing, so to make it pretty we just need CSS 
style.

make build-doc

calls dtplite and produces this under doc/html

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Fwd: [TCLCORE] Can Tcl_GetObjResult() return shared object?

[Zoran V. <zv...@ar...>]

On 23.09.2006, at 23:30, Vlad Seryakov wrote:

> tclxkeylist.c is the place where i see a lot of such usage

I will check this again. I thought I got all the occurences...

Re: [naviserver-devel] Fwd: [TCLCORE] Can Tcl_GetObjResult() return shared object?

[Vlad S. <vl...@cr...>]

tclxkeylist.c is the place where i see a lot of such usage

Zoran Vasiljevic wrote:
> Hi!
> 
> As I expected...
> 
> Begin forwarded message:
> 
>> From: Joe English <jen...@fl...>
>> Date: 23. September 2006 19:15:35 MESZ
>> To: Tcl Core List <tcl...@li...>
>> Subject: Re: [TCLCORE] Can Tcl_GetObjResult() return shared object?
>>
>>
>> Zoran Vasiljevic wrote:
>>> I'm not sure about that, but I had a couple of issues
>>> which I can only track to the above being true
>>> (not 100% confirmed but I suspect seriously).
>>>
>>> Is/can that be true?
>> Yes, that's definitely true.  Tcl_GetObjResult() *can* return
>> a shared object.
>>
>>> If yes, one should avoid constructs like:
>>>
>>>     Tcl_SetStringObj(Tcl_GetObjResult(interp), thestring,  
>>> stringlength);
>> Yes, one should absolutely avoid such constructs.
>> It can lead to Tcl_Panic()s when you least expect them.
>>
>> There used to be a number of them in the core, specifically
>> the idiom:
>>
>> 	Tcl_AppendToObj(Tcl_GetObjResult(interp), ...);
>>
>> as a replacement for Tcl_AppendResult().  Fortunately most of
>> these have been fixed by now.
>>
>>> and use:
>>>
>>>     Tcl_SetObjResult(interp, Tcl_NewStringObj(thestring,  
>>> stringlength));
>>>
>>> instead [...]?
>> Yes, do that instead.
>>
>>
>> --Joe English
>>
>> ---------------------------------------------------------------------- 
>> ---
>> 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
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] Fwd: [TCLCORE] Can Tcl_GetObjResult() return shared object?

[Zoran V. <zv...@ar...>]

Hi!

As I expected...

Begin forwarded message:

> From: Joe English <jen...@fl...>
> Date: 23. September 2006 19:15:35 MESZ
> To: Tcl Core List <tcl...@li...>
> Subject: Re: [TCLCORE] Can Tcl_GetObjResult() return shared object?
>
>
> Zoran Vasiljevic wrote:
>>
>> I'm not sure about that, but I had a couple of issues
>> which I can only track to the above being true
>> (not 100% confirmed but I suspect seriously).
>>
>> Is/can that be true?
>
> Yes, that's definitely true.  Tcl_GetObjResult() *can* return
> a shared object.
>
>> If yes, one should avoid constructs like:
>>
>>     Tcl_SetStringObj(Tcl_GetObjResult(interp), thestring,  
>> stringlength);
>
> Yes, one should absolutely avoid such constructs.
> It can lead to Tcl_Panic()s when you least expect them.
>
> There used to be a number of them in the core, specifically
> the idiom:
>
> 	Tcl_AppendToObj(Tcl_GetObjResult(interp), ...);
>
> as a replacement for Tcl_AppendResult().  Fortunately most of
> these have been fixed by now.
>
>> and use:
>>
>>     Tcl_SetObjResult(interp, Tcl_NewStringObj(thestring,  
>> stringlength));
>>
>> instead [...]?
>
> Yes, do that instead.
>
>
> --Joe English
>
> ---------------------------------------------------------------------- 
> ---
> 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
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [naviserver-devel] Tcl object handling

[Zoran V. <zv...@ar...>]

On 23.09.2006, at 13:37, Gustaf Neumann wrote:

> Not sure, what's faster, resetResult() + setIntObj() or
> setObjResult() + newIntObj(). The difference in speed is most likely
> not significant. however, resetResult allows to append to the object,
> clears error state, etc.

I believe that either/or is OK to use as both will be
almost the same as fast (or as slow). It is thus a
matter of personal taste wether to write:

   Tcl_ResetResult(interp):
   Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);

or

   Tcl_SetObjResult(interp, Tcl_NewIntObj(1));

The only "problem" I have with the first case
is that is pretty "weird", as lots of assumptions
are made and code ist not that clear. But, as
said, people are free to use either/or.

I still have to go to tcl core-list and get this
one straighten out, as I would really like to know
wether:

   Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);

constructs can be used w/o a side effect.
I guess, the main thing to ask is:

   Can Tcl_GetObjResult() return shared object?

Cheers
Zoran

Re: [naviserver-devel] Tcl object handling

[Gustaf N. <ne...@wu...>]

Zoran Vasiljevic schrieb:
> Hi!
>
> After I have observed some very subtle and hard-to-reproduce
> bugs in our app, I found out that Tcl object handling in
> some places in NS code, although "by the book" is really a
> source of trouble. Like:
>
>     Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);   /* Unsafe? */
>
> This construct assumes that object stored in the interp
> result is not shared.

> But, when I modify it to look like:
>
>    Tcl_SetObjResult(interp, Tcl_NewIntObj(1));    /* Safe! */
>
>   

Another option is to use
Tcl_ResetResult()

 * Side effects:
 *    It resets the result object to an unshared empty object. It
 *    then restores the interpreter's string result area to its default
 *    initialized state, freeing up any memory that may have been
 *    allocated. It also clears any error information for the interpreter.

When i developed the byte-code support for xotcl, i found some
subtle differences on that, depending on byte-code-compiled code or
not (this was with some earlier tcl 8.4 versions).

Not sure, what's faster, resetResult() + setIntObj() or
setObjResult() + newIntObj(). The difference in speed is most likely
not significant. however, resetResult allows to append to the object,
clears error state, etc.

-gustaf

[naviserver-devel] Tcl object handling

[Zoran V. <zv...@ar...>]

Hi!

After I have observed some very subtle and hard-to-reproduce
bugs in our app, I found out that Tcl object handling in
some places in NS code, although "by the book" is really a
source of trouble. Like:

    Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);   /* Unsafe? */

This construct assumes that object stored in the interp
result is not shared. I do not know, and I will have to
make the journey on Tcl core list, if it is possible to
have a shared object in the interp result or not, but it
seems to me that it is. OR, there is some other source or
problem which I do not know.
But, when I modify it to look like:

   Tcl_SetObjResult(interp, Tcl_NewIntObj(1));    /* Safe! */

then all works fine. This is not only the case with the
Int but with all other object types as well.

Difference between the two is that the first one saves
creation of a new Tcl object, as it re-uses the one stored
in the interp result. But, creation of Tcl object is relatively
cheap operation (pop from the list) so there is not really much
that it's saved.

I have gone thru the sources and replaced all those "problematic"
spots and would kindly ask any C-code commiter to pay attention
to the above. Until we explicitly find out what is happening and
why, I'd consider the above construct "unsafe" and would refrain
from using it.

Thanks
Zoran

Re: [naviserver-devel] SVN repository

[Zoran V. <zv...@ar...>]

On 21.09.2006, at 07:29, Bernd Eidenschink wrote:

> You have very tough requirements for your revision control system  
> and made
> that very clear.

Ah, no.. tough it is not: simple to use, must do the job.
That isn't tough. It is just that I do not see any benefit.
Therefore I asked about what _is_ really the benefit of svn
compared to cvs that would justify the move. After all,
we have so many things that we want to do, that time of the
universe will not be enough for all. Instead of pouring
precious time in some "fancy" new tool, I'd rather stick
to what I have as long as it does the job fine and is convenient
and simple to use. So far cvs has been doing the job OK and
I could not see what svn can do better, looking at our
(moderate) needs.

Re: [naviserver-devel] SVN repository

[Bernd E. <eid...@we...>]

> On 20.09.2006, at 17:53, Bernd Eidenschink wrote:
> > If you have the client installed, simply try for a checkout:
> >
> > # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/
> > naviserver
>
> Simple? Simple???
[...]
>There you go. What is simple here? My (pessimistic, but close to  
>reality)
>experience tells me (and this keeps prooving itself) that NOTHING
>(I mean really _NOTHING_) is simple.

Zoran, this became a self-fullfilling prophecy! 
I'm not the scapegoat here: I am not paid to play an evangelist of SVN and 
gave an example of the usage after you wrote:

>Provided we all agree (count me in)
>when/how you plan to do it?

which gave me the impression you are somewhat ready for a test so I added 
examples of usage. I use SVN at work, I think it's better, but it does 
_absolutely not matter_ to me if it is used by everyone and every project 
(again: absolutely not! I don't care). I'm convinced it can be a real benefit 
if you can't stay with some CVS oddities, but I know as well: Never change a 
running system.

You have very tough requirements for your revision control system and made 
that very clear.

Don't switch.

Bernd.

Re: [naviserver-devel] SVN repository

[Zoran V. <zv...@ar...>]

On 20.09.2006, at 21:36, Vlad Seryakov wrote:

> In out simplest case no benefits because out repository structure does
> not change often. It is just more modern source control thing, but we
> can stay on CVS.

OK. More (or less) modern, I do not care. It has to do the job
and be reasonably simple to use, which cvs is.
I would say: if ain't broken, don't fix it. We have enough
"construction sites" to take care of, which are more important.

Re: [naviserver-devel] SVN repository

[Vlad S. <vl...@cr...>]

In out simplest case no benefits because out repository structure does 
not change often. It is just more modern source control thing, but we 
can stay on CVS.

Zoran Vasiljevic wrote:
> On 20.09.2006, at 21:26, Vlad Seryakov wrote:
> 
>> Strange, i just ran this command i did not have error messages
> 
> Yes. I tried it again and it worked here as well.
> It seems that this thing is not that stable as
> one would think...
> 
> I sill miss the real benefit. As we are not hosting
> the repository, what obvious benefits we will get from svn?
> I mostly do cvs update, cvs commit and sometimes cvs diff.
> Very seldom cvs rtag.
> So, how is this svn going to change my life (to better)
> if I now use svn instead of cvs? I still see no benefit
> but I'm sure you can tell me couple of them.
> 
> 
> 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] SVN repository

[Zoran V. <zv...@ar...>]

On 20.09.2006, at 21:26, Vlad Seryakov wrote:

> Strange, i just ran this command i did not have error messages

Yes. I tried it again and it worked here as well.
It seems that this thing is not that stable as
one would think...

I sill miss the real benefit. As we are not hosting
the repository, what obvious benefits we will get from svn?
I mostly do cvs update, cvs commit and sometimes cvs diff.
Very seldom cvs rtag.
So, how is this svn going to change my life (to better)
if I now use svn instead of cvs? I still see no benefit
but I'm sure you can tell me couple of them.

Re: [naviserver-devel] SVN repository

[Vlad S. <vl...@cr...>]

Strange, i just ran this command i did not have error messages

user/passwd it will ask on commit

Zoran Vasiljevic wrote:
> On 20.09.2006, at 17:53, Bernd Eidenschink wrote:
> 
>> If you have the client installed, simply try for a checkout:
>>
>> # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/  
>> naviserver
> 
> Simple? Simple???
> 
> After some struggle, I got that svn client installaed.
> And:
> 
> zvpb:~/sf/svn zoran$ svn co https://svn.sourceforge.net/svnroot/ 
> naviserver/trunk/ naviserver
> Error validating server certificate for 'https://svn.sourceforge.net: 
> 443':
> - The certificate is not issued by a trusted authority. Use the
>     fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: *.sourceforge.net
> - Valid: from Dec  8 13:40:07 2005 GMT until Feb  7 13:40:07 2007 GMT
> - Issuer: Equifax Secure Certificate Authority, Equifax, US
> - Fingerprint: 49:b8:cb:87:04:8c:49:39:45:83:dd:4c:cf:c7:54:57:b0:9e: 
> 84:5d
> (R)eject, accept (t)emporarily or accept (p)ermanently? p
> svn: PROPFIND request failed on '/svnroot/naviserver/trunk'
> svn: PROPFIND of '/svnroot/naviserver/trunk': Could not read status  
> line: Secure connection truncated (https://svn.sourceforge.net)
> 
> There you go. What is simple here? My (pessimistic, but close to  
> reality)
> experience tells me (and this keeps prooving itself) that NOTHING
> (I mean really _NOTHING_) is simple.
> 
> Also, I do not understand where is the username/password here?
> Who asks me for the username/password? 
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] SVN repository

[Zoran V. <zv...@ar...>]

On 20.09.2006, at 17:53, Bernd Eidenschink wrote:

>
> If you have the client installed, simply try for a checkout:
>
> # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/  
> naviserver

Simple? Simple???

After some struggle, I got that svn client installaed.
And:

zvpb:~/sf/svn zoran$ svn co https://svn.sourceforge.net/svnroot/ 
naviserver/trunk/ naviserver
Error validating server certificate for 'https://svn.sourceforge.net: 
443':
- The certificate is not issued by a trusted authority. Use the
    fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.sourceforge.net
- Valid: from Dec  8 13:40:07 2005 GMT until Feb  7 13:40:07 2007 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: 49:b8:cb:87:04:8c:49:39:45:83:dd:4c:cf:c7:54:57:b0:9e: 
84:5d
(R)eject, accept (t)emporarily or accept (p)ermanently? p
svn: PROPFIND request failed on '/svnroot/naviserver/trunk'
svn: PROPFIND of '/svnroot/naviserver/trunk': Could not read status  
line: Secure connection truncated (https://svn.sourceforge.net)

There you go. What is simple here? My (pessimistic, but close to  
reality)
experience tells me (and this keeps prooving itself) that NOTHING
(I mean really _NOTHING_) is simple.

Also, I do not understand where is the username/password here?
Who asks me for the username/password?