headers
Daniel Shahaf | 1 Jan 2012 03:21

Re: Problems with the documentation of Subversion dump format

Mark Mielke wrote on Sat, Dec 31, 2011 at 01:00:12 -0500:
> On 12/30/2011 09:35 PM, Daniel Shahaf wrote:
> >Mark Mielke wrote on Fri, Dec 30, 2011 at 20:22:50 -0500:
> >
> >>I think you are not understanding my concern. If svn:author is only
> >>ever displayed to the user - then "authenticated username" may not
> >>be a desirable form to use. For teams of 10 people, sure you can
> >>recognize the uid of everybody in the team. But what about teams of
> >>100, or teams of 1000?
> >AuthLDAPRemoteUserAttribute cn
> >
> >Then you can do
> >
> >% svn commit --username "Daniel Shahaf"
> >
> >and the logs will show
> >
> >------------------------------------------------------------------------
> >r1 | Daniel Shahaf | strftime(...) | 1 line
> >------------------------------------------------------------------------
> 
> We use this for a few services - but note how now instead of losing
> the full name, it now loses the unique identifier. In a company of
> 1,000+ people, there is a good chance for overlap of "cn". There
> might be only one Mark Mielke, but other names such as John Sullivan
> there could be many. The "cn" is not a unique identifier and cannot
> be used to key off. It is for display purposes only.
> 

Another idea is to change the revprop's value in the pre-commit or
(Continue reading)

Permalink | Reply | 32 comments |
headers
Mark Mielke | 1 Jan 2012 09:53

Re: Problems with the documentation of Subversion dump format

On 12/31/2011 09:21 PM, Daniel Shahaf wrote:
> Mark Mielke wrote on Sat, Dec 31, 2011 at 01:00:12 -0500:
>> On 12/30/2011 09:35 PM, Daniel Shahaf wrote:
>>> AuthLDAPRemoteUserAttribute cn
>>>
>>> Then you can do
>>>
>>> % svn commit --username "Daniel Shahaf"
>>>
>>> and the logs will show
>>>
>>> ------------------------------------------------------------------------
>>> r1 | Daniel Shahaf | strftime(...) | 1 line
>>> ------------------------------------------------------------------------
>> We use this for a few services - but note how now instead of losing
>> the full name, it now loses the unique identifier. In a company of
>> 1,000+ people, there is a good chance for overlap of "cn". There
>> might be only one Mark Mielke, but other names such as John Sullivan
>> there could be many. The "cn" is not a unique identifier and cannot
>> be used to key off. It is for display purposes only.
>>
> Another idea is to change the revprop's value in the pre-commit or
> post-commit hook:
>      ..
>      author=`svnlook propget --revprop -t $TXN svn:author`
>      svnadmin setrevprop -t $TXN svn:author "`getent passwd $author | cut -d: -f5 | cut -d, -f1`<$author <at> localdomain>"
>      ..
> and then people still authenticate with their uid's, but all existing
> tools will automatically show DVCS-style name+address author names.
(Continue reading)

Permalink | Reply | 31 comments |
headers
Jonathan Nieder | 1 Jan 2012 23:31
Picon

[1.7.x] "svn update" tripping assertion when replacing executable by symlink (Re: [bug?] perl bindings: SVN::Ra->new trips assertion when file:// URL contains a space)

Stefan Sperling wrote:
> On Sat, Dec 17, 2011 at 03:40:03AM -0600, Jonathan Nieder wrote:

>> 	svn: E235000: In file '/home/jrn/src/subversion/subversion/libsvn_wc/update_editor.c' line
1582: assertion failed (action == svn_wc_conflict_action_edit || action ==
svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
>> 	Aborted (core dumped)
>> 
>
> That looks like the symlink update bug fixed in 1.7.2
>
> Version 1.7.2
> (02 Dec 2011, from /branches/1.7.x)
> http://svn.apache.org/repos/asf/subversion/tags/1.7.2
>    [...]
>    * fix an assertion failure when a symlink is updated (r1186944, -81, -83)

That sounds right.  Unfortunately, I can reproduce it with
branches/1.7.x <at> 1226297.

Some details:

The action is _add.  The test script ran "svn update" after a
typechange (executable -> symlink) for a file named exec.sh.  reason
is _replaced.  The base status is _normal.

"svn log -v" reveals that /exec.sh is already present and already
known to be a symlink.  However, the working copy is not up-to-date
--- the working copy of the file is still an executable.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stefan Sperling | 2 Jan 2012 00:52
Picon

Re: [1.7.x] "svn update" tripping assertion when replacing executable by symlink (Re: [bug?] perl bindings: SVN::Ra->new trips assertion when file:// URL contains a space)

On Sun, Jan 01, 2012 at 04:31:14PM -0600, Jonathan Nieder wrote:
> Stefan Sperling wrote:
> > On Sat, Dec 17, 2011 at 03:40:03AM -0600, Jonathan Nieder wrote:
> 
> >> 	svn: E235000: In file '/home/jrn/src/subversion/subversion/libsvn_wc/update_editor.c' line
1582: assertion failed (action == svn_wc_conflict_action_edit || action ==
svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
> >> 	Aborted (core dumped)
> >> 
> >
> > That looks like the symlink update bug fixed in 1.7.2
> >
> > Version 1.7.2
> > (02 Dec 2011, from /branches/1.7.x)
> > http://svn.apache.org/repos/asf/subversion/tags/1.7.2
> >    [...]
> >    * fix an assertion failure when a symlink is updated (r1186944, -81, -83)
> 
> That sounds right.  Unfortunately, I can reproduce it with
> branches/1.7.x <at> 1226297.
> 
> Some details:
> 
> The action is _add.  The test script ran "svn update" after a
> typechange (executable -> symlink) for a file named exec.sh.  reason
> is _replaced.  The base status is _normal.
> 
> "svn log -v" reveals that /exec.sh is already present and already
> known to be a symlink.  However, the working copy is not up-to-date
> --- the working copy of the file is still an executable.
(Continue reading)

Permalink | Reply | 4 comments |
headers
neels | 2 Jan 2012 03:26
Picon
Favicon

[svnbench] Revision: 1226324 compiled Jan 2 2012, 00:21:26

/home/neels/svnbench/20120102-002446
Started at Mon Jan  2 00:24:46 UTC 2012

*Disclaimer:* this tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.

Averaged-total results across all runs:
---------------------------------------

COMPARE total_1.7.x to total_trunk
  TOTAL RUN timings: 229.5 seconds avg for total_1.7.x
                     175.3 seconds avg for total_trunk
      avg         operation
   0.76|-54.223   TOTAL RUN
   0.88| -0.003   add
   0.86| -0.157   checkout
   0.87| -2.051   commit
   1.02| +0.004   copy
   0.81| -0.070   delete
   0.12| -5.621   info
   0.82| -1.341   merge
   0.64| -0.007   mkdir
   0.83| -0.002   prop mod
   0.72| -0.003   propdel
   0.84| -0.001   proplist
   0.85| -0.002   propset
   0.86| -0.001   resolve
   0.92| -0.019   resolved
   0.93| -0.016   status
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Nieder | 2 Jan 2012 05:38
Picon

Re: [1.7.x] "svn update" tripping assertion when replacing executable by symlink (Re: [bug?] perl bindings: SVN::Ra->new trips assertion when file:// URL contains a space)

Stefan Sperling wrote:

> Sounds like we should apply your Ra.pm patch and also backport r1187692.

I applied r1187692 on top of the 1.7.x branch here to see how it
fares.  This time:

 $ svn update
 Updating '.':
 svn: E155010: The node '/home/jrn/src/git/t/trash
directory.t9100-git-svn-basic/.git/svn/refs/remotes/git-svn/svn-tree/exec.sh' was not found.

Haven't tried trunk yet.  Reproduction recipe below[1].

> The test suite you mentioned which triggers the assertion failure fixed
> by your Ra.pm patch is the git-svn test suite, is it? I think our own
> test suite should be updated to check for this, too.

Yep, it's t9100-git-svn-basic.sh from the git-svn test suite.  Adding
tests to the svn test suite to cover these things sounds like a very
good idea.  I'll try to get time to do so and will be happy to review
tests if someone else starts the work.

Thanks for your thoughtfulness,
Jonathan

[1] Recipe:

	svnadmin create /tmp/test.repo
	<test.dump svnadmin load /tmp/test.repo
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Nieder | 2 Jan 2012 08:29
Picon

svn update: error replacing executable by symlink ("svn: E155010: The node '/tmp/working-copy/exec.sh' was not found.")

Jonathan Nieder wrote:

> Haven't tried trunk yet.
[...]
>	svnadmin create /tmp/test.repo
>	<test.dump svnadmin load /tmp/test.repo
>	svn checkout -r4 file:///tmp/test.repo working-copy
>	cd working-copy
>	svn update
>
> Expected result: executable changes to symlink.
> Actual result: svn: E155010: The node '/tmp/working-copy/exec.sh' was not found.

Happens with trunk <at> 1226348, too.
Permalink | Reply | 1 comment |
headers
Alan Barrett | 2 Jan 2012 08:52
Gravatar

format of svn:author

On Sun, 01 Jan 2012, Mark Mielke wrote:
>> Another idea is to change the revprop's value in the pre-commit 
>> or post-commit hook: [...]
>
> This is what we've been doing for about two years. It has 
> the consequence that tools don't automatically match unique 
> identifier to commit as they no longer match.

If your third party tools can't extract the unique ID from 
svn:author = "Display Name <uniqueid <at> domain>" then perhaps the 
problem lies at least as much in your third party tools as in 
subversion.

--apb (Alan Barrett)
Permalink | Reply | 30 comments |
headers
Mark Mielke | 2 Jan 2012 09:34

Re: format of svn:author

On 01/02/2012 02:52 AM, Alan Barrett wrote:
> On Sun, 01 Jan 2012, Mark Mielke wrote:
>>> Another idea is to change the revprop's value in the pre-commit or 
>>> post-commit hook: [...]
>>
>> This is what we've been doing for about two years. It has the 
>> consequence that tools don't automatically match unique identifier to 
>> commit as they no longer match.
>
> If your third party tools can't extract the unique ID from svn:author 
> = "Display Name <uniqueid <at> domain>" then perhaps the problem lies at 
> least as much in your third party tools as in subversion.

I wonder if you thought this through before posting. :-)

You are saying that if I make up an essentially arbitrary scheme, such 
as "Display Name <uniqueid <at> domain>", and you have a tool which is 
unaware of my scheme, and therefore your tool fails to matches users in 
the region because of my scheme - that your tool has the problem? 
Despite the documentation for Subversion never mentioning or even 
suggesting a convention that you should be responsible for understanding?

No.

The convention must be defined in the Subversion book, and it must be 
part of the release notes so that third party tools adhere to the 
convention.

Otherwise, only extremely casual interpretation can be done of the 
field. For example, it can be treated as a unique identifier - but more
(Continue reading)

Permalink | Reply | 29 comments |
headers
Alan Barrett | 2 Jan 2012 10:48
Gravatar

Re: format of svn:author

On Mon, 02 Jan 2012, Mark Mielke wrote:
>> If your third party tools can't extract the unique ID from 
>> svn:author = "Display Name <uniqueid <at> domain>" then perhaps the 
>> problem lies at least as much in your third party tools as in 
>> subversion.
>
> I wonder if you thought this through before posting. :-)
>
> You are saying that if I make up an essentially arbitrary 
> scheme, such as "Display Name <uniqueid <at> domain>", and you have 
> a tool which is unaware of my scheme, and therefore your tool 
> fails to matches users in the region because of my scheme - that 
> your tool has the problem?

It's a free text field, although it's probably a bad idea to put 
more than one line of text there.  As the administrator who sets 
up the svn repository, you are responsible for choosing what text 
you put in svn:author.  If, as you said, you have tools that want 
to be able to map it to a a more restricted type, such as a login 
name, or employee number, or (part of) an email address, then the 
tool is responsible for performing the mapping.  If the tool can't 
perform the mapping then, yes, I say that the tool is incompatible 
with the way the repository administrator has chosen to use the 
svn:author field.

> Otherwise, only extremely casual interpretation can be done of 
> the field. For example, it can be treated as a unique identifier 
> - but more like a "foreign key" unique identifier in the sense 
> that it is a key in some domain, but not necessarily a domain I 
> know about or am an authority for.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane