headers
Daniel Rall | 1 May 2007 01:03
Favicon

Re: MT 'blame' and 'log' Auditing - Design Specification

On Sat, 28 Apr 2007, Hyrum K. Wright wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Phippard wrote:
> > I still do not agree with this part of the spec:
> > 
> > svn blame
> >    Two additional columns for each line, with the original revision
> > and author of that line. Unlike other commands, we do not need to
> > worry about multiple source revisions, because each line can have at
> > most one author.
> > 
> > 
> > I object to the two additional columns.  If I run svn blame
> > --merge-sensitive I do not need to see any other information.  I
> > thought at one point we even said that were it not for the expected
> > performance hit in getting the merge information that svn blame should
> > just always return this information.  When using blame it is not
> > likely that someone would want any other information.
> 
> I agree.  I was surprised to see that still in the spec.
> 
> The comments made elsethread about returning both sets of data through
> the blame API express a valid concern.  This should be fairly easy to
> accommodate; the command-line client can just filter this output, while
> other clients can cache it or hide it pending a checkbox or whatever
> else they please.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lakshman | 1 May 2007 01:36
Picon

Re: svnserve logging


Hi Ben,

Thanks for your quick response.

Does that mean that we can't debug svnserve errors. Is there not **any**
logs.

If there are any log files I could use, could you please point me to the
location to debug an issue with svnserve.
The only logs I could find where /var/log/secure & /var/log/messages.

The issue details are at
http://www.nabble.com/Connection-closed-unexpectedly-tf3668425.html#a10249901

Thanks
Lakshman

Ben Collins-Sussman-3 wrote:
> 
> No students took up the task.
> 
> On 4/29/07, Lakshman <lakshman.srilakshmanan <at> tradingpost.com.au> wrote:
>>
>> Any update on this ?
>>
>> Thanks
>> Lakshman
>>
>> Ben Collins-Sussman-3 wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Gilbert | 1 May 2007 03:07
Picon
Favicon

Re: abort() calls

At 08:22 PM 4/30/2007 +0200, Brane wrote:
>Jonathan Gilbert wrote:
>> What about -- on platforms that support it -- allowing the project calling
>> into the library to provide a jmp_buf to be longjmp()ed to instead of
>> abort()ing, and replacing the abort() calls with calls to a wrapper
>> function to pick between that and abort() if the user hasn't provided a
>> jmp_buf (or the platform doesn't support it)?
>>   
>
>The number of implicit +1s to this proposal really make hair stand on end.
>
>The following really applies to any kind of abort() alternative, but
>longjmp sticks out.
>
>    * How do you get the right jmp_buf to all the necessary places in
>      all the Subversion libraries? we don't pass around a context
>      object where it could be stored.

If it is added to libsvn_subr, is that not available from every other part
of Subversion? It can't be that hard to find one central place to put it.

>    * What do you do with dangling resources (open files, etc.) that
>      can't be cleaned up after a longjmp?

I thought Subversion allocated everything in APR pools. Won't that take
care of this? If a caller places his setjmp() in such a way that he loses
pointers to allocated objects when the longjmp() occurs, well, that's his
problem; he has the option of placing it right next to the Subversion
library and not having a problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Phippard | 1 May 2007 04:02
Picon
Gravatar

Test failure on Windows

Just built and ran tests  <at> r24856 on OS X and Windows.  OS X was fine
but on Windows I got some failures:

XPASS: copy_tests.py 50: move file using relative dst path names
XPASS: copy_tests.py 52: copy file using relative dst path names
FAIL:  stat_tests.py 5: status on versioned items whose type has changed

I believe the first two are expected because I built with APR 1.2.8.
The stat failure is new though.  Here is output from tests.log:

CMD: svnadmin.exe "create" "svn-test-work\repositories\stat_tests-5"
"--bdb-txn-nosync" "--fs-type=fsfs" <TIME = 1.672000>
CMD: svnadmin.exe dump "svn-test-work\local_tmp\repos" | svnadmin.exe
load "svn-test-work\repositories\stat_tests-5" <TIME = 0.031000>
CMD: svn.exe "co" "--username" "jrandom" "--password" "rayjandom"
"file:///C:/svn/src-trunk/Release/subversion/tests/cmdline/svn-test-work/repositories/stat_tests-5"
"svn-test-work\working_copies\stat_tests-5" "--config-dir"
"C:\svn\src-trunk\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config"
<TIME = 1.641000>
UNEXPECTED EXCEPTION:
Traceback (most recent call last):
  File "C:\svn\src-trunk\subversion\tests\cmdline\svntest\main.py",
line 782, in run
    rc = apply(self.pred.run, (), kw)
  File "C:\svn\src-trunk\subversion\tests\cmdline\svntest\testcase.py",
line 116, in run
    return self.func(sandbox)
  File "C:\svn\src-trunk\subversion/tests/cmdline/stat_tests.py", line
190, in status_type_change
    os.rename('A', 'iota')
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Burba | 1 May 2007 04:03
Favicon
Gravatar

RE: Shortcut for '--merge-sensitive'

> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_wright <at> mail.utexas.edu] 
> Sent: Monday, April 30, 2007 2:32 PM
> To: dev <at> subversion.tigris.org
> Subject: Shortcut for '--merge-sensitive'
> 
> In the course of adding auditing ability to the Subversion 
> command line client, we've assumed the existence of the 
> '--merge-sensitive' switch, and some single character 
> shortcut for it.  A couple of suggestions have come up for 
> what the shortcut should be, so I'm presenting them here, and 
> letting folks bikeshed about it.  The two that have been propsed
> are: '-g' and '-M'.
> 
> I prefer '-g', mainly because it is lowercase and '-M' could 
> be confused with '-m'.

Paint that bikeshed '-g'reen.
Permalink | Reply | 1 comment |
headers
Ben Collins-Sussman | 1 May 2007 04:46
Favicon
Gravatar

Re: svnserve logging

On 4/30/07, Lakshman <lakshman.srilakshmanan <at> tradingpost.com.au> wrote:
>
> Hi Ben,
>
> Thanks for your quick response.
>
> Does that mean that we can't debug svnserve errors. Is there not **any**
> logs.

Sure you can debug svnserve.  Just run it in gdb, and connect to it in
the usual way.

No, there are no logs.
Permalink | Reply | 0 comments |
headers
Lieven Govaerts | 1 May 2007 08:37
Picon

Re: Test failure on Windows

Mark Phippard wrote:
>
> UNEXPECTED EXCEPTION:
> Traceback (most recent call last):
>  File "C:\svn\src-trunk\subversion\tests\cmdline\svntest\main.py",
> line 782, in run
>    rc = apply(self.pred.run, (), kw)
>  File "C:\svn\src-trunk\subversion\tests\cmdline\svntest\testcase.py",
> line 116, in run
>    return self.func(sandbox)
>  File "C:\svn\src-trunk\subversion/tests/cmdline/stat_tests.py", line
> 190, in status_type_change
>    os.rename('A', 'iota')
> WindowsError: [Error 13] Access is denied
> FAIL:  stat_tests.py 5: status on versioned items whose type has changed
I bet if you run the test again it will pass just fine. The test is
renaming a versioned directory A to iota. Any process that has a file
open in that directory will block the rename.

Check TortoiseSVN and virus scanners. In TSVN in the 'Icon Overlays' tab
you can add paths to exclude from handling.

hth,

Lieven
Permalink | Reply | 0 comments |
headers
Mark Reibert | 1 May 2007 09:39

Re: abort() calls

On Mon, 2007-04-30 at 16:03 -0400, C. Michael Pilato wrote:
> For myself, I try to apply the simple rule of thumb that abort() is useful
> for punishing naughty programmers (that is, those who pass malformed data
> into functions they call), but otherwise, it's probably a return-an-error
> situation.  Bad data on disk doesn't violate the API contract, so ideally
> shouldn't trigger an abort.

Whereas I understand your distinction, this punitive approach seems a
bit draconian. After all, nobody would expect acos(2.0) to abort() just
because the caller does not understand trigonometry.

At the very least an application should be able to communicate with the
user if and when it is going down. Libraries taking down apps - even if
there is no sane path forward - removes this very important capability
from the application programmer.

--

-- 
----------------------
Mark S. Reibert, Ph.D.
svn <at> reibert.com
----------------------
Permalink | Reply | 1 comment |
headers
Serge Adda | 1 May 2007 10:44
Favicon

RE: Re: FEATURE REQUEST: Property and Keyword Substitution

I see that an impressive work has already been done.

It is going far beyond what I had in minds.

Looking briefly at the patches it seems that most of the initial
specifications have already been implemented, except the "%p".

What else is missing? Configuration files management?

Thank You,
Serge

-----Original Message-----
From: John Peacock [mailto:jpeacock <at> rowman.com] 
Sent: Monday, April 30, 2007 6:19 PM
To: Serge Adda
Cc: dev <at> subversion.tigris.org
Subject: Re: FETAURE REQUEST: Property and Keyword Substitution

Serge Adda wrote:
> If there is no way to find the previous work, I will try to write my
own
> prototype.

The initial code to convert keywords to a hash internally was committed 
in December of 2005, see the original incident:

	http://subversion.tigris.org/issues/show_bug.cgi?id=890

but the design discussion of how to handle properties substituted as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Malcolm Rowe | 1 May 2007 11:13
Picon

Re: [PATCH] Make DAV activity db location configurable

On Mon, Apr 30, 2007 at 10:43:32AM -0700, Eric Gillespie wrote:
> Make the location of mod_dav_svn's activity database configurable with a
> new SVNActivitiesDB configuration directive.  If set, use it directly as
> the activity db for SVNPath repositories.  For SVNParentPath repositories,
> use it to contain activity db directories named after the repository
> basename.  If this directive is not specified, use "dav/activities.d" at
> the top of the repository.

It's a pity that we can't define the default behaviour of
SVNActivitiesDB in terms of a valid value, but I guess that's okay.  Do
we need to document this new directive somewhere?

+1, looks good - you just need to update some comments to reflect the
change to create the dav directory if --pre-1.4-compatible.

One in the log message:

> * subversion/libsvn_repos/repos.c
>   (create_svn_repos_t): Don't fill in dav_path.
>   (create_repos_structure): Take fs_config argument and create the
>     "dav" path (SVN_REPOS__DAV_DIR) only if it has the
>     SVN_FS_CONFIG_PRE_1_5_COMPATIBLE setting.

And one in the comments:

> ]]]
> 
> Index: subversion/libsvn_repos/repos.c
> ===================================================================
> -  /* Create the DAV sandbox directory.  */
(Continue reading)

Permalink | Reply | 1 comment |

Gmane