Re: Modifying commit messages

[Jonathan Oulds]

Thank you for your response,

The problem with keeping a versioned list of bugs in a file is that it 
only allows you to update the list in the revision that relates to the 
day you found the bug, and not the day you caused the bug.


Example:
The head of /trunk is at revision 500, I have three branches A, B and C 
taken from revisions 50, 100 and 150 respectively of the trunk.  Now 
during testing I discover a bug BZ123 that was introduced at revision 
100 so I update the bug list file in branches B and C; this works fine 
until I decide to create another branch from revision 125, BZ123 is not 
in my bug list text file at revision 125 so I would need to examine the 
head bug list file and copy across the bug numbers that are relevant. 
I'm not saying your system will not work, but when you take into 
account, merging and reverting etc.  it all becomes a headache for the 
maintainer.


I did initially consider a simple text file but rejected it for the 
above reasons.  Please let me know if I've misunderstood your 
suggestion.  After all I'm looking for the simplest solution.


Jonathan.

On 13/01/2011 18:20, Pablo Beltran wrote:

I think it will work but you don't need to change the commit message to
achieve that. You can create a plain text file (bug list) and versioning
it in Subversion.

For example, you may use this simple format:

...
bug x: r1, r2, r3
bug y: r2, r7
.

and look for revision numbers in the list instead of bug names.

Example:
"does bug x appears in branch y?"
It's the same that checking  whether any revision number retrieved from
/svn log "branch y" /is present in the record for the "bug x" (r1,r2 or
r3 in the example).

I think that writing that script is also quite simple and the solution
more maintainable and traceable. I think (not sure) that changing commit
messages is out of version control scope and you would loss traceability
with your solution: today you may think that "bug x" was introduced in
r1 and  appears in "branch y". Next week, you might discover that "bug
x" was really introduced in r2 and then appears in "branch z" but not in
"branch y". Sou you should change again the comment for r1 to reflect
that really it was not the introduction of the bug. If you forget do it,
surely next moth you will try to fix a bug on "branch y" which was not
affected by the bug.


I have another question. Would you need to answer "where does bug x
appears?"

Pablo.

On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds
mailto:jonathan_ou...@mcafee.com>> wrote:

Hello,

Currently we track bug fixes by including a reference number within
the commit message, I'm sure this is common practice.

However we would also like to keep track of the revision where bugs
were introduced.  As a use case, consider a project with many
branches and tags, now imagine that a bug is discovered to have been
introduced at an early stage of the project e.g. revision 100.  All
branches taken after revision 100 will potentially have the bug all
branches taken prior to revision 100 will not.  The problem here is
that as the number of bugs and branches increase the job of
answering the question "does bug x appear in branch y?" becomes ever
more difficult.

As a possible solution we are considering modifying commit messages
to indicate the bugs introduced in each revision.  It should then be
possible to answer the above question with a simple svn log + grep.

I would be interested to hear any feedback the community has on this.
Jonathan Oulds

Re: Modifying commit messages

[Jonathan Oulds]

On 13/01/2011 20:08, Ryan Schmidt wrote:


On Jan 13, 2011, at 10:46, Jonathan Oulds wrote:


consider a project with many branches and tags, now imagine that a bug is 
discovered to have been introduced at an early stage of the project e.g. 
revision 100.  All branches taken after revision 100 will potentially have the 
bug all branches taken prior to revision 100 will not.


That's not necessarily true -- a branch taken before revision 100 could still 
contain the bug, if the revision that caused the bug is later merged into that 
branch. So I'm not sure your proposal actually helps solve a problem. It sounds 
like the problem is identifying which branches contain a particular bug, and 
I'd say you have to test each branch -- check out the branch, build your 
software, run it, see if it exhibits the problem. Then merge the fix from trunk 
if it's needed.




My understanding of svn log is that you can use the -g switch to include 
comments from the merge history.


Example:
I take branch A from /trunk at revision 50, later I introduce a bug at 
revision 100 of /trunk at revision 200 I merge /trunk into branch A, now 
at revision 500 I spot my mistake and amend the log entry for /trunk@100.


Now if I do svn log -g branches/A surely I will see the updated log 
entry identifying the bug, because the -g switch pulls in the log 
entries from the merged revisions including the amended log entry.


Jonathan.

Re: Modifying commit messages

[Pablo Beltran]

Where is the bug file versioned? I think that is the point. In my opinion it
should not be versioned across branches because that would be a headache.
Hence it should not be placed under the trunk and you might create a new
directory "bugs" at the same level that trunk, tags and branches. In that
way, you will not create new versions of the bug file every time the trunk
is copied.

In your example, the content of the file (.../project z/bugs/list.txt )
would be:

.
BZ123: 100
.

all the time (until other bug is found and the bug list is updated)

You would get these results after executing the script:

bug_finder.sh A  (<- Nothing)
bug_finder.sh B (<- Found bug BZ123 at r100)
bug_finder.sh C (<- Found bug BZ123 at r100)
bug_finder.sh D (<- Found bug BZ123 at r100) (This is the branch created at
r125)

That would happen because the r100 belongs to the log of B,C and D but not
A.

Normally, you would use the HEAD revision of the bug file. But you have also
the history of your bugs (log of the bug file) what might be very helpful.


On Fri, Jan 14, 2011 at 10:26 AM, Jonathan Oulds
wrote:

> Thank you for your response,
>
> The problem with keeping a versioned list of bugs in a file is that it only
> allows you to update the list in the revision that relates to the day you
> found the bug, and not the day you caused the bug.
>
> Example:
> The head of /trunk is at revision 500, I have three branches A, B and C
> taken from revisions 50, 100 and 150 respectively of the trunk.  Now during
> testing I discover a bug BZ123 that was introduced at revision 100 so I
> update the bug list file in branches B and C; this works fine until I decide
> to create another branch from revision 125, BZ123 is not in my bug list text
> file at revision 125 so I would need to examine the head bug list file and
> copy across the bug numbers that are relevant. I'm not saying your system
> will not work, but when you take into account, merging and reverting etc.
>  it all becomes a headache for the maintainer.
>
> I did initially consider a simple text file but rejected it for the above
> reasons.  Please let me know if I've misunderstood your suggestion.  After
> all I'm looking for the simplest solution.
>
> Jonathan.
>
>
> On 13/01/2011 18:20, Pablo Beltran wrote:
>
>> I think it will work but you don't need to change the commit message to
>> achieve that. You can create a plain text file (bug list) and versioning
>> it in Subversion.
>>
>> For example, you may use this simple format:
>>
>> ...
>> bug x: r1, r2, r3
>> bug y: r2, r7
>> .
>>
>> and look for revision numbers in the list instead of bug names.
>>
>> Example:
>> "does bug x appears in branch y?"
>> It's the same that checking  whether any revision number retrieved from
>> /svn log "branch y" /is present in the record for the "bug x" (r1,r2 or
>> r3 in the example).
>>
>> I think that writing that script is also quite simple and the solution
>> more maintainable and traceable. I think (not sure) that changing commit
>> messages is out of version control scope and you would loss traceability
>> with your solution: today you may think that "bug x" was introduced in
>> r1 and  appears in "branch y". Next week, you might discover that "bug
>> x" was really introduced in r2 and then appears in "branch z" but not in
>> "branch y". Sou you should change again the comment for r1 to reflect
>> that really it was not the introduction of the bug. If you forget do it,
>> surely next moth you will try to fix a bug on "branch y" which was not
>> affected by the bug.
>>
>>
>> I have another question. Would you need to answer "where does bug x
>> appears?"
>>
>> Pablo.
>>
>> On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds
>> mailto:jonathan_ou...@mcafee.com>> wrote:
>>
>>Hello,
>>
>>Currently we track bug fixes by including a reference number within
>>the commit message, I'm sure this is common practice.
>>
>>However we would also like to keep track of the revision where bugs
>>were introduced.  As a use case, consider a project with many
>>branches and tags, now imagine that a bug is discovered to have been
>>introduced at an early stage of the project e.g. revision 100.  All
>>branches taken after revision 100 will potentially have the bug all
>>branches taken prior to revision 100 will not.  The problem here is
>>that as the number of bugs and branches increase the job of
>>answering the question "does bug x appear in branch y?" becomes ever
>>more difficult.
>>
>>As a possible solution we are considering modifying commit messages
>>to indicate the bugs introduced in each revision.  It should then be
>>possible to answer the above question with a simple svn log + grep.
>>
>>I would be interested to hear any feedback the community has on this.
>>Jonathan Oulds
>>
>>
>>
>

Re: Modifying commit messages

[Thorsten Schöning]

Guten Tag Jonathan Oulds,
am Donnerstag, 13. Januar 2011 um 17:46 schrieben Sie:

> Currently we track bug fixes by including a reference number within the
> commit message, I'm sure this is common practice.

If you already use a bug tracker, doesn't that provide a mechanism to
file bugs against multiple versions or maybe clone bugs into multiple
versions? Bugzilla for example does the latter, at least in my old
2.22.x, which wouldn't directly answer the question which bug does
span over multiple versions. But what you could do is create some
master bug for your error and dependant bugs for each version in which
this error occurs. At least you could use the reporting tools of your
bug tracker.

In my opinion, depending on the concrete bug and how important it has
to be fixed and all that stuff, having more than one bug for the
different versions is of benefit if you think of things like branches
which aren't supported anymore and therefore don't need a bug fix,
some need a fix but not now, for some branches this bug is a show
stopper etc. I would use the bug tracker for such things.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Modifying commit messages

[Jonathan Oulds]

We do use Bugzilla to track issues, you are correct that you can file 
the bug against multiple branches and we do.


However, what if a branch is created after the bug has been added to 
Bugzilla.  Someone would have to manually inspect the revision at which 
the branch was taken and create another set of Bugzilla issues for the 
new branch for all the bugs that were present at that time of branching.


This to me seems to be the problem with issue tracking and branching, 
keeping the two synchronised.


However, what if you could do an "svn log -g" and compare the results 
with a Bugzilla search to prove that all known bugs were also present in 
Bugzilla for that branch?


Jonathan.


On 14/01/2011 10:56, Thorsten Schöning wrote:

Guten Tag Jonathan Oulds,
am Donnerstag, 13. Januar 2011 um 17:46 schrieben Sie:


Currently we track bug fixes by including a reference number within the
commit message, I'm sure this is common practice.


If you already use a bug tracker, doesn't that provide a mechanism to
file bugs against multiple versions or maybe clone bugs into multiple
versions? Bugzilla for example does the latter, at least in my old
2.22.x, which wouldn't directly answer the question which bug does
span over multiple versions. But what you could do is create some
master bug for your error and dependant bugs for each version in which
this error occurs. At least you could use the reporting tools of your
bug tracker.

In my opinion, depending on the concrete bug and how important it has
to be fixed and all that stuff, having more than one bug for the
different versions is of benefit if you think of things like branches
which aren't supported anymore and therefore don't need a bug fix,
some need a fix but not now, for some branches this bug is a show
stopper etc. I would use the bug tracker for such things.

Mit freundlichen Grüßen,

Thorsten Schöning

Re: Modifying commit messages

[Jonathan Oulds]

Okay, I see what you are driving at here.

We write a script that takes the branch URL plus the buglist file, the 
script performs an svn log -g -v to get a list of all the revision 
numbers that went into that branch then compares those against the head 
revision of the buglist file.


Yes, that is a nice solution.  I believe it is analogous to what I 
originally proposed, but without the need to modify the commit message.


Thank you
Jonathan



On 14/01/2011 10:21, Pablo Beltran wrote:

Where is the bug file versioned? I think that is the point. In my
opinion it should not be versioned across branches because that would be
a headache. Hence it should not be placed under the trunk and you might
create a new directory "bugs" at the same level that trunk, tags and
branches. In that way, you will not create new versions of the bug file
every time the trunk is copied.

In your example, the content of the file (.../project z/bugs/list.txt )
would be:

.
BZ123: 100
.

all the time (until other bug is found and the bug list is updated)

You would get these results after executing the script:

bug_finder.sh A  (<- Nothing)
bug_finder.sh B (<- Found bug BZ123 at r100)
bug_finder.sh C (<- Found bug BZ123 at r100)
bug_finder.sh D (<- Found bug BZ123 at r100) (This is the branch created
at r125)

That would happen because the r100 belongs to the log of B,C and D but
not A.

Normally, you would use the HEAD revision of the bug file. But you have
also the history of your bugs (log of the bug file) what might be very
helpful.


On Fri, Jan 14, 2011 at 10:26 AM, Jonathan Oulds
mailto:jonathan_ou...@mcafee.com>> wrote:

Thank you for your response,

The problem with keeping a versioned list of bugs in a file is that
it only allows you to update the list in the revision that relates
to the day you found the bug, and not the day you caused the bug.

Example:
The head of /trunk is at revision 500, I have three branches A, B
and C taken from revisions 50, 100 and 150 respectively of the
trunk.  Now during testing I discover a bug BZ123 that was
introduced at revision 100 so I update the bug list file in branches
B and C; this works fine until I decide to create another branch
from revision 125, BZ123 is not in my bug list text file at revision
125 so I would need to examine the head bug list file and copy
across the bug numbers that are relevant. I'm not saying your system
will not work, but when you take into account, merging and reverting
etc.  it all becomes a headache for the maintainer.

I did initially consider a simple text file but rejected it for the
above reasons.  Please let me know if I've misunderstood your
suggestion.  After all I'm looking for the simplest solution.

Jonathan.


On 13/01/2011 18:20, Pablo Beltran wrote:

I think it will work but you don't need to change the commit
message to
achieve that. You can create a plain text file (bug list) and
versioning
it in Subversion.

For example, you may use this simple format:

...
bug x: r1, r2, r3
bug y: r2, r7
.

and look for revision numbers in the list instead of bug names.

Example:
"does bug x appears in branch y?"
It's the same that checking  whether any revision number
retrieved from
/svn log "branch y" /is present in the record for the "bug x"
(r1,r2 or
r3 in the example).

I think that writing that script is also quite simple and the
solution
more maintainable and traceable. I think (not sure) that
changing commit
messages is out of version control scope and you would loss
traceability
with your solution: today you may think that "bug x" was
introduced in
r1 and  appears in "branch y". Next week, you might discover
that "bug
x" was really introduced in r2 and then appears in "branch z"
but not in
"branch y". Sou you should change again the comment for r1 to
reflect
that really it was not the introduction of the bug. If you
forget do it,
surely next moth you will try to fix a bug on "branch y" which
was not
affected by the bug.


I have another question. Would you need to answer "where does bug x
appears?"

Pablo.

On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds
mailto:jonathan_ou...@mcafee.com>
>> wrote:

Hello,

Currently we track bug fixes by including a reference number
within
the commit message, I'm sure this is common practice.

However we would also like to keep track of the revision
where bugs
were introduced.  As a use case, consider a p

Svn authentication issue (was: "rejected Basic challenge"...)

[Cooke, Mark]

Dear List,

Replying to myself in the hope this may catch some more eyes.  More info
inline below... 

> -Original Message-
> From: Cooke, Mark 
> Sent: 12 January 2011 11:42
> Subject: "rejected Basic challenge" for one user only (Win/apache)
> 
> Hello,
> 
> We use TortoiseSVN from windows XP SP3 clients (required by corporate
> policy) to connect to repos on windows server 2003:-
> 
> Apache/2.2.17 (Win32) DAV/2 mod_ssl/2.2.17 OpenSSL/0.9.8o mod_wsgi/3.3
> Python/2.6.4 SVN/1.6.15
> 
> I have one single user (amongst 15 or so) who is experiencing
> authentication issues and need some help in working out what is wrong
> for him alone.
> 
> Background:
> 
> We moved to svn and Trac about 18 months ago (when I joined) and I
> have configured everything.  We started using mod_sspi for 
> authentication as I could not understand (nor get local help for)
> the decorated names etc used by LDAP.  That was working but then
> this one user stopped being able to use svn at all.  As he had
> trouble accessing the server at all (which uses SSL and global
> authentication) I blamed SSPI and finally found the info I needed
> to get LDAP working against our Active Directory forest.
> 
> My user can now access the server and browse the source tree fine
> (I use the TortoiseSVN xslt config and each department has their
> own parentpath set of repos).  However, he still cannot checkout
> or update.  From using tortoise we installed svn command line that
> we use on the server (from alagazam, thanks David Darj!) and we
> are seeing the following error:
> 
> Authentication realm:  Dept 
> Applications server
> Password for 'user_a': *
> Authentication realm:  Dept 
> Applications server
> Username: domain\user_a
> Password for 'domain\user_a': *
> Authentication realm:  Dept 
> Applications server
> 
> Username: svn: OPTIONS of
> 'https://server.company.net/svn/dept/project/trunk': authorization
> failed: Could not authenticate to server: rejected Basic challenge
> (https://server.company.net)
> 
> We know the same username/password works against the apache server and
> we use the same authz file for path based authentication from both
> apache and subversion direct.  All other users work OK, just this one
> user is having problems.  We have cleared all cached data using
> tortoise then uninstalled and rebooted before re-installing tortoise.
> We then tried the svn cli again (generating the info above) to make 
> sure it was svn and not specific to tortoise.
> 
> Here is the sanitised authentication section from httpd conf (I know
> Basic is plain text but all traffic is redirected to SSL https and the
> standard client here is IE6):
> 
> 
> Order allow,deny
> Allow from all
> 
> AuthName "Dept Applications server"
> AuthType Basic
> AuthBasicProvider ldap
> AuthzLDAPAuthoritative on
> 
> # The LDAP query URL
> AuthLDAPURL
> "ldap://adserver:3268/DC=blah,DC=blah,DC=blah?sAMAccountName,m
> ail?sub?(objectClass=*)" TLS
> 
> # Active Directory requires an authenticating DN to access records
> AuthLDAPBindDN 
> AuthLDAPBindPassword 
> 
> Require valid-user
> 
> 
> ...and the department svn root:
> 
> 
> DAV svn
> SVNIndexXSLT "/subversion/svnindex.xsl"
> SVNParentPath D:/svn/dept/
> SVNListParentPath On
> # restrict access to subversion repository paths...
> AuthzForceUsernameCase Lower
> AuthzSVNAccessFile d:/path-to/svn-users.txt
> 
> 
> ...and the relevant bits of svn-users.txt:
> 
> [aliases]
> bryanb = user_a
> 
> # Give all authenticated users read access to the root
> # NB: use "* = " for all [repo:/] sections to remove access
> [/]
> &bryanb = rw
> user_a = rw
> 
> ...note that I have granted rights to both the alias and the user's
> ID to see if that helped (no change).
> 
> Finally, here are sample errors from the apache log file:
> 
> [Wed Jan 12 10:06:38 2011] [error] [client ip-address] user user_a:
> authentication failure for "/svn/dept/project/trunk": 
> Password Mismatch
> [Wed Jan 12 10:18:42 2011] [error] [client ip-address] user
> domain\\user_a not found: /svn/dept/project/trunk
> 
> I do not understand where the 'Password Mismatch' error is 
> coming from, why does that only happen when using subversion
> and not the browser?  I have tried searching for "rejected Basic
> challenge" (both svn.haxx.se and the wider net) but I've not found
> anything that hes helped so far.
> 
>From what I have found, this should indicate that the server is
rejecting the cached credentials and so the client is prompting for
updated credentials.  However, the user can browse the repos using IE
and https through the server (which applies blanket authorisation
through the  directive) which makes me suspect svn somehow
instead of apache.

I have also tried disabling the AuthzSVNAccessFile (including bouncing
apache) but that made no diffe

Problem with merging

[peter . schweizer]

Hi Folks,

i want to merge a branch into trunk. For that i got the first revision
of the branch with (svn log --stop-on-copy => 2854). Now i want to
merge with "svn merge -r 2854:3143 ^/branches/mybranch ." in a trunk
working dir. Svn now tries to merge the trunk not with the newest
files in the branch BUT uses revision 3095 for merging.

My question is, why does svn use the 3095 as branches' "HEAD". This
doesnt make sense to me.

Regards,
Peter

Re: Problem with merging

[Stefan Sperling]

On Fri, Jan 14, 2011 at 02:12:56PM +0100, peter.schwei...@gmail.com wrote:
> Hi Folks,
> 
> i want to merge a branch into trunk. For that i got the first revision
> of the branch with (svn log --stop-on-copy => 2854). Now i want to
> merge with "svn merge -r 2854:3143 ^/branches/mybranch ." in a trunk
> working dir.

You need to use the --reintegrate option to merge branches back to trunk.
See 
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Stefan

Re: Problem with merging

[peter . schweizer]

Thx very much, that solved my problem :-)

Strangely, until now i was able to merge branches into trunk without
this option

Regards,
Peter

On Fri, Jan 14, 2011 at 2:42 PM, Stefan Sperling  wrote:
> On Fri, Jan 14, 2011 at 02:12:56PM +0100, peter.schwei...@gmail.com wrote:
>> Hi Folks,
>>
>> i want to merge a branch into trunk. For that i got the first revision
>> of the branch with (svn log --stop-on-copy => 2854). Now i want to
>> merge with "svn merge -r 2854:3143 ^/branches/mybranch ." in a trunk
>> working dir.
>
> You need to use the --reintegrate option to merge branches back to trunk.
> See 
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
>
> Stefan
>

Re: Problem with merging

[Stefan Sperling]

On Fri, Jan 14, 2011 at 02:53:11PM +0100, peter.schwei...@gmail.com wrote:
> Thx very much, that solved my problem :-)
> 
> Strangely, until now i was able to merge branches into trunk without
> this option
> 

You got lucky. The --reintegrate option is quite important.
See 
http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E

Stefan

RE: Trival merge of big text file: Dismal performance, 540x faster if binary.

[Andreas Krüger, DV-RATIO]

Hello, Johan and all,

first, for the record, here is another comparison between
binary and text merge performance, this time with the files
generated by my script (repeated below):

Binary merge took 3.56 seconds, text merge took 3:45:45.202 hours.
In this particular case, binary merge performance was 3805 times
faster than text merge performance.



> Textual merging in svn makes use of a variant of the standard diff
> algorithm, namely diff3.  Just a couple of days ago, I finally
> succeeded in making diff3 take advantage of ... performance
> improvements ... .

Good news! Excellent! Thank you!

But... does this relate to my problem?

The improved diff3 will give a nice performance improvement in the
*general* case.

I certainly want that improvement!


Another nice performance improvement of a factor of several hundreds
(or thousands) could be obtained for big files in the *trivial* case,
if SVN didn't diff3 at all, but simply copied the result.

I also want this other improvement!


Finally:

SVN already contains the intelligence needed to find out whether a
merge is trivial or not.  For, in the binary case, the trivial merges
are precisely the ones that SVN knows how to do.


Johan (or whoever else), please kindly enlighten me, should I be
missing something!

Regards, Andreas
--
Dr. Andreas Krüger, Senior Developer

Tel. (+49) (211) 280 69-1132
andreas.krue...@hp.com

DV-RATIO NORDWEST GmbH, Habsburgerstraße 12, 40547 Düsseldorf, Germany
 
für
 
Hewlett-Packard GmbH H Herrenberger Str. 140   71034 Böblingen   www.hp.com/de
Geschäftsführer: Volker Smid (Vorsitzender), Michael Eberhardt, Thorsten 
Herrmann,
Martin Kinne, Heiko Meyer, Ernst Reichart, Rainer Sterk
Vorsitzender des Aufsichtsrates: Jörg Menno Harms
Sitz der Gesellschaft: Böblingen S Amtsgericht Stuttgart HRB 244081   
WEEE-Reg.-Nr. DE 30409072

-Original Message-
From: krueger, Andreas (Andreas Krüger, DV-RATIO) 
Sent: Thursday, January 13, 2011 4:08 PM
To: users@subversion.apache.org
Subject: RE: Trival merge of big text file: Dismal performance, 540x faster if 
binary.

...


#!/usr/bin/perl -w

# Generate stupid files on stdout.

use strict;

# For the overhauled file, set to 1:
my $overhaul = 0;

my $number = 1;

for (1 .. 100) {

# 1073741824 and 910111213 have no common divisor,
# so this will take a while before it repeats.
$number = ($number + 910111213) % 1073741824;

my $printme;
if($overhaul) {
$printme = ($number % 4 != 0 ? $number * 13 % 1073741824 : $number);
} else {
$printme = $number;
}
print $printme,"\n";
}

SVN 1.6.15 checkout fails on particular file

[KARR, DAVID (ATTSI)]

This is a continuation of my experiences described in the "What SVN
command-line client distro should I get to work properly with SVN 1.4.x
on the server?" subject.

My SVN server is running version 1.4.x.  I'm using the latest Subversive
in Eclipse, but the connector associated with SVN 1.5.6.  This works
well enough in Eclipse.

I installed SVN 1.6.15 from CollabNet.  I created a new directory from
the shell and did a checkout of two of the projects I have checked out
in Eclipse.  One of them completed successfully, but another one fails
each time with an error like the following:

svn: Your .svn/tmp directory may be missing or corrupt; run 'svn
cleanup' and try again
svn: Can't open file '...\.svn\tmp\text-base\svn-base': The system
cannot find the path specified.

I elided the full path to the file.

I looked in the "text-base" directory being referenced here, and it's
empty.

I did a "svn cleanup", and it chugged for a second and then went back to
the prompt.

I tried the checkout again, and it failed with the exact same error.

I also tried changing into the directory and doing "svn update", and
that also failed with the same error.

Any ideas?

RE: SVN 1.6.15 checkout fails on particular file

[Tony Sweeney]

You can't mix Subversion client releases where the middle digit of the
version number differs.  Subversion clients are backwards compatible
when talking to the server, but not when writing workspace metadata to
the filesystem.  You can, in theory, use whatever version you like on
the client side against any server version.  However, when you invoke a
client on a workspace, it checks to see if the local metadata is the
same version as itself, and if it discovers an older version, silently
upgrades the format to its own.  At this point, older clients will no
longer work on that workspace.

Tony.

> -Original Message-
> From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] 
> Sent: 14 January 2011 18:36
> To: users@subversion.apache.org
> Subject: SVN 1.6.15 checkout fails on particular file
> 
> This is a continuation of my experiences described in the 
> "What SVN command-line client distro should I get to work 
> properly with SVN 1.4.x on the server?" subject.
> 
> My SVN server is running version 1.4.x.  I'm using the latest 
> Subversive in Eclipse, but the connector associated with SVN 
> 1.5.6.  This works well enough in Eclipse.
> 
> I installed SVN 1.6.15 from CollabNet.  I created a new 
> directory from the shell and did a checkout of two of the 
> projects I have checked out in Eclipse.  One of them 
> completed successfully, but another one fails each time with 
> an error like the following:
> 
> svn: Your .svn/tmp directory may be missing or corrupt; run 
> 'svn cleanup' and try again
> svn: Can't open file '...\.svn\tmp\text-base\svn-base': 
> The system cannot find the path specified.
> 
> I elided the full path to the file.
> 
> I looked in the "text-base" directory being referenced here, 
> and it's empty.
> 
> I did a "svn cleanup", and it chugged for a second and then 
> went back to the prompt.
> 
> I tried the checkout again, and it failed with the exact same error.
> 
> I also tried changing into the directory and doing "svn 
> update", and that also failed with the same error.
> 
> Any ideas?
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: SVN 1.6.15 checkout fails on particular file

[KARR, DAVID (ATTSI)]

> -Original Message-
> From: Tony Sweeney [mailto:tswee...@omnifone.com]
> Sent: Friday, January 14, 2011 10:57 AM
> To: KARR, DAVID (ATTSI); users@subversion.apache.org
> Subject: RE: SVN 1.6.15 checkout fails on particular file
> 
> You can't mix Subversion client releases where the middle digit of the
> version number differs.  Subversion clients are backwards compatible
> when talking to the server, but not when writing workspace metadata to
> the filesystem.  You can, in theory, use whatever version you like on
> the client side against any server version.  However, when you invoke
a
> client on a workspace, it checks to see if the local metadata is the
> same version as itself, and if it discovers an older version, silently
> upgrades the format to its own.  At this point, older clients will no
> longer work on that workspace.

Just so we're clear here, I have these projects checked out in Eclipse,
but not in the same directory that I'm trying to do the command-line
checkout.  I'm trying to do a separate checkout of these projects, just
using the 1.6.15 client.  I'm not using multiple client versions in the
same checked-out directory, but I am attempting to checkout a module
from SVN with the 1.6.15 client that has been previously checked out
with different client versions.

Is the conflict in mixing client versions relevant to the module in the
server, or in the client-side directory?  If it's the latter, then there
should be no conflict, as I'm only using the 1.6.15 client in this
directory.

> > -Original Message-
> > From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com]
> > Sent: 14 January 2011 18:36
> > To: users@subversion.apache.org
> > Subject: SVN 1.6.15 checkout fails on particular file
> >
> > This is a continuation of my experiences described in the
> > "What SVN command-line client distro should I get to work
> > properly with SVN 1.4.x on the server?" subject.
> >
> > My SVN server is running version 1.4.x.  I'm using the latest
> > Subversive in Eclipse, but the connector associated with SVN
> > 1.5.6.  This works well enough in Eclipse.
> >
> > I installed SVN 1.6.15 from CollabNet.  I created a new
> > directory from the shell and did a checkout of two of the
> > projects I have checked out in Eclipse.  One of them
> > completed successfully, but another one fails each time with
> > an error like the following:
> >
> > svn: Your .svn/tmp directory may be missing or corrupt; run
> > 'svn cleanup' and try again
> > svn: Can't open file '...\.svn\tmp\text-base\svn-base':
> > The system cannot find the path specified.
> >
> > I elided the full path to the file.
> >
> > I looked in the "text-base" directory being referenced here,
> > and it's empty.
> >
> > I did a "svn cleanup", and it chugged for a second and then
> > went back to the prompt.
> >
> > I tried the checkout again, and it failed with the exact same error.
> >
> > I also tried changing into the directory and doing "svn
> > update", and that also failed with the same error.
> >
> > Any ideas?
> >
> >
> >
> __
> > This email has been scanned by the MessageLabs Email Security
System.
> > For more information please visit
> > http://www.messagelabs.com/email
> >
> __
> >

Re: SVN 1.6.15 checkout fails on particular file

[Mark Phippard]

On Fri, Jan 14, 2011 at 2:06 PM, KARR, DAVID (ATTSI)  wrote:

> Just so we're clear here, I have these projects checked out in Eclipse,
> but not in the same directory that I'm trying to do the command-line
> checkout.  I'm trying to do a separate checkout of these projects, just
> using the 1.6.15 client.  I'm not using multiple client versions in the
> same checked-out directory, but I am attempting to checkout a module
> from SVN with the 1.6.15 client that has been previously checked out
> with different client versions.

As long as you are careful this is fine.  The tool to watch out for is
TortoiseSVN.  Since it runs in Windows explorer you have to be sure
not to even browse into these folders or else TortoiseSVN code is
triggered and it can update the working copy.  Using the command line
it is obviously easier to avoid the working copies you do not want to
touch.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN 1.6.15 checkout fails on particular file

[Tony Sweeney]

 

> -Original Message-
> From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] 
> Sent: 14 January 2011 19:07
> To: Tony Sweeney; users@subversion.apache.org
> Subject: RE: SVN 1.6.15 checkout fails on particular file
> 
> > -Original Message-
> > From: Tony Sweeney [mailto:tswee...@omnifone.com]
> > Sent: Friday, January 14, 2011 10:57 AM
> > To: KARR, DAVID (ATTSI); users@subversion.apache.org
> > Subject: RE: SVN 1.6.15 checkout fails on particular file
> > 
> > You can't mix Subversion client releases where the middle 
> digit of the 
> > version number differs.  Subversion clients are backwards 
> compatible 
> > when talking to the server, but not when writing workspace 
> metadata to 
> > the filesystem.  You can, in theory, use whatever version 
> you like on 
> > the client side against any server version.  However, when 
> you invoke
> a
> > client on a workspace, it checks to see if the local 
> metadata is the 
> > same version as itself, and if it discovers an older 
> version, silently 
> > upgrades the format to its own.  At this point, older 
> clients will no 
> > longer work on that workspace.
> 
> Just so we're clear here, I have these projects checked out 
> in Eclipse, but not in the same directory that I'm trying to 
> do the command-line checkout.  I'm trying to do a separate 
> checkout of these projects, just using the 1.6.15 client.  
> I'm not using multiple client versions in the same 
> checked-out directory, but I am attempting to checkout a 
> module from SVN with the 1.6.15 client that has been 
> previously checked out with different client versions.
> 
> Is the conflict in mixing client versions relevant to the 
> module in the server, or in the client-side directory?  If 
> it's the latter, then there should be no conflict, as I'm 
> only using the 1.6.15 client in this directory.
> 

Only in the client.  If your workspaces are disjoint then that should
have worked.  Subversion doesn't keep any record of workspace state
(more's the pity).

Tony.

Re: SVN 1.6.15 checkout fails on particular file

[Johan Corveleyn]

On Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI)  wrote:
> This is a continuation of my experiences described in the "What SVN
> command-line client distro should I get to work properly with SVN 1.4.x
> on the server?" subject.
>
> My SVN server is running version 1.4.x.  I'm using the latest Subversive
> in Eclipse, but the connector associated with SVN 1.5.6.  This works
> well enough in Eclipse.
>
> I installed SVN 1.6.15 from CollabNet.  I created a new directory from
> the shell and did a checkout of two of the projects I have checked out
> in Eclipse.  One of them completed successfully, but another one fails
> each time with an error like the following:
>
> svn: Your .svn/tmp directory may be missing or corrupt; run 'svn
> cleanup' and try again
> svn: Can't open file '...\.svn\tmp\text-base\svn-base': The system
> cannot find the path specified.
>
> I elided the full path to the file.
>
> I looked in the "text-base" directory being referenced here, and it's
> empty.
>
> I did a "svn cleanup", and it chugged for a second and then went back to
> the prompt.
>
> I tried the checkout again, and it failed with the exact same error.
>
> I also tried changing into the directory and doing "svn update", and
> that also failed with the same error.
>
> Any ideas?

Could it be that there are case-clashing filenames in that directory,
which you are trying to checkout on a case-insensitive filesystem
(since you are on Windows)?

Perhaps someone committed two files to the repository that only differ
in case, like readme.txt and README.TXT. If you try to check this out
on a case-insensitive filesystem, it will fail. You should be able to
see exactly what's in the repository by running "svn ls $URL".

Cheers,
-- 
Johan

RE: SVN 1.6.15 checkout fails on particular file

[KARR, DAVID (ATTSI)]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Friday, January 14, 2011 11:35 AM
> To: KARR, DAVID (ATTSI)
> Cc: users@subversion.apache.org
> Subject: Re: SVN 1.6.15 checkout fails on particular file
> 
> On Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI) 
> wrote:
> > This is a continuation of my experiences described in the "What SVN
> > command-line client distro should I get to work properly with SVN
> 1.4.x
> > on the server?" subject.
> >
> > My SVN server is running version 1.4.x.  I'm using the latest
> Subversive
> > in Eclipse, but the connector associated with SVN 1.5.6.  This works
> > well enough in Eclipse.
> >
> > I installed SVN 1.6.15 from CollabNet.  I created a new directory
> from
> > the shell and did a checkout of two of the projects I have checked
> out
> > in Eclipse.  One of them completed successfully, but another one
> fails
> > each time with an error like the following:
> >
> > svn: Your .svn/tmp directory may be missing or corrupt; run 'svn
> > cleanup' and try again
> > svn: Can't open file '...\.svn\tmp\text-base\svn-base': The
> system
> > cannot find the path specified.
> >
> > I elided the full path to the file.
> >
> > I looked in the "text-base" directory being referenced here, and it's
> > empty.
> >
> > I did a "svn cleanup", and it chugged for a second and then went back
> to
> > the prompt.
> >
> > I tried the checkout again, and it failed with the exact same error.
> >
> > I also tried changing into the directory and doing "svn update", and
> > that also failed with the same error.
> >
> > Any ideas?
> 
> Could it be that there are case-clashing filenames in that directory,
> which you are trying to checkout on a case-insensitive filesystem
> (since you are on Windows)?
> 
> Perhaps someone committed two files to the repository that only differ
> in case, like readme.txt and README.TXT. If you try to check this out
> on a case-insensitive filesystem, it will fail. You should be able to
> see exactly what's in the repository by running "svn ls $URL".

Hmm.  I think I found a big clue.  When I do the checkout, I'm giving it an 
alternate name.  The "svn checkout" doc is clear that this is legal.  In other 
words, I'm doing "svn checkout svn:... desiredname".

I've tried doing this several times, and it almost always fails on trying to 
check out this particular file.

I just tried doing the checkout again, but without the alternate name, and it 
completed without error.

I then tried changing the checkout to use a "simpler" alternate name.  I was 
using a name like "projectname-branch".  I then tried "projectname-a".  Both of 
these fail.  If I instead use an alternate name of "a", or "projectname" (using 
the original project name), or "a-a", those all succeed.

I then tried using an alternate name of "projectnamexx".  That fails with the 
same error.

I then tried "abcdefghijklmnopqr" (actually all the iterations before that), 
and that succeeds, but "abcdefghijklmnopqrs" (one more letter) fails.

I then looked at the full local path this file would represent, and the entire 
path is 260 characters long.  I would think if there's any threshold, it would 
be at 255, not 259.

Any idea what's going on here?

> 
> Cheers,
> --
> Johan

Re: SVN 1.6.15 checkout fails on particular file

[Ryan Schmidt]

On Jan 14, 2011, at 14:19, KARR, DAVID (ATTSI) wrote:

> Hmm.  I think I found a big clue.  When I do the checkout, I'm giving it an 
> alternate name.  The "svn checkout" doc is clear that this is legal.  In 
> other words, I'm doing "svn checkout svn:... desiredname".
> 
> I've tried doing this several times, and it almost always fails on trying to 
> check out this particular file.
> 
> I just tried doing the checkout again, but without the alternate name, and it 
> completed without error.
> 
> I then tried changing the checkout to use a "simpler" alternate name.  I was 
> using a name like "projectname-branch".  I then tried "projectname-a".  Both 
> of these fail.  If I instead use an alternate name of "a", or "projectname" 
> (using the original project name), or "a-a", those all succeed.
> 
> I then tried using an alternate name of "projectnamexx".  That fails with the 
> same error.
> 
> I then tried "abcdefghijklmnopqr" (actually all the iterations before that), 
> and that succeeds, but "abcdefghijklmnopqrs" (one more letter) fails.
> 
> I then looked at the full local path this file would represent, and the 
> entire path is 260 characters long.  I would think if there's any threshold, 
> it would be at 255, not 259.
> 
> Any idea what's going on here?

I don't know what the exact limit is, but it is around 255, and you've clearly 
hit it, and will need to content yourself with using shorter paths.

All Current Committers: Free Tickets for Subversion 2011

[David Richards]

Just a short note to extend an offer of free tickets to any of the
Subversion committers who might want attend any of the Subversion Live 2011
events in San Francisco (Silicon Valley), Boston, MA or London (England).

More info is here: http://goo.gl/ogtdE

You will need a special discount code to attend and we can provide this -
just drop an email to events ( at ) WANdisco.com.


--
Regards,

David Richards
President & CEO
WANdisco, Inc.


Free Online Subversion Training
http://svn.wandisco.com/eTraining

Join the Open Source Subversion Community
http://svn.wandisco.com/eCommunity

Read our blogs!
http://blogs.wandisco.com/

Follow us on Twitter
http://svn.wandisco.com/eTwitter

Join us on facebook!
http://svn.wandisco.com/eFacebook

Re: SVN 1.6.15 checkout fails on particular file

[David Huang]

On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
> I then looked at the full local path this file would represent, and the 
> entire path is 260 characters long.  I would think if there's any threshold, 
> it would be at 255, not 259.
> 
> Any idea what's going on here?


The usual maximum path length limit on Windows is indeed 259 (or 260 if you 
count the terminating NUL): See the "Maximum Path Length Limitation" section of 
http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx

-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

RE: SVN 1.6.15 checkout fails on particular file

[KARR, DAVID (ATTSI)]

> -Original Message-
> From: David Huang [mailto:k...@azeotrope.org]
> Sent: Friday, January 14, 2011 1:29 PM
> To: KARR, DAVID (ATTSI)
> Cc: users@subversion.apache.org
> Subject: Re: SVN 1.6.15 checkout fails on particular file
> 
> 
> On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
> > I then looked at the full local path this file would represent, and
> the entire path is 260 characters long.  I would think if there's any
> threshold, it would be at 255, not 259.
> >
> > Any idea what's going on here?
> 
> The usual maximum path length limit on Windows is indeed 259 (or 260
if
> you count the terminating NUL): See the "Maximum Path Length
> Limitation" section of http://msdn.microsoft.com/en-
> us/library/aa365247%28v=vs.85%29.aspx

Hmm, then Eclipse/Subversion must be doing something special to avoid
this problem.  My resulting paths in my existing projects checked out in
Eclipse are quite a bit longer than 259 characters.

Compiling subversion on Ubuntu 10.10

[Daniel Becroft]

Hi,

I've had some issues compiling Subversion and APR in my Ubuntu environment
(the below output is done from /trunk - I haven't tried a 1.6.x branch yet).

Running ./autogen.sh and ./configure work correctly, however I get the
following error when running 'make':

-- making all in apr
make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr'
make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr'
sed 's,^\(location=\).*$,\1installed,' < apr-1-config > apr-config.out
sed 's,^\(apr_build.*=\).*$,\1/usr/local/apr/build-1,' <
build/apr_rules.mk> build/apr_rules.out
make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr'
make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr'
-- completed all in apr
-- making all in apr-util
make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr-util'
Making all in xml/expat
make[2]: Entering directory
`/home/djcbecroft/dev/subversion/apr-util/xml/expat'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/djcbecroft/dev/subversion/apr-util/xml/expat'
make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr-util'
/bin/bash /libtool --silent --mode=compile gcc -g -O2 -pthread
-DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-I/home/djcbecroft/dev/subversion/apr-util/include
-I/home/djcbecroft/dev/subversion/apr-util/include/private
-I/home/djcbecroft/dev/subversion/apr/include
-I/home/djcbecroft/dev/subversion/apr-util/xml/expat/lib  -o
buckets/apr_brigade.lo -c buckets/apr_brigade.c && touch
buckets/apr_brigade.lo
/bin/bash: /libtool: No such file or directory
make[2]: *** [buckets/apr_brigade.lo] Error 127
make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util'
make: *** [external-all] Error 1

After investigation, it seems that the path for LIBTOOL was defined
incorrectly. I had to change apr-util/build/rules.mk:38 from:

LIBTOOL=$(SHELL) $(top_builddir)/libtool
to
LIBTOOL=$(SHELL) $(apr_builddir)/libtool

I'm unfamiliar with how the configure scripts work, so I'm not sure if this
is a problem with the SVN scripts, APR scripts, or my system itself. If it's
one of the first two, then I'll report it to the appropriate list. Can
anyone provide any guidance?
---
Daniel Becroft

Re: Compiling subversion on Ubuntu 10.10

[Daniel Becroft]

Apologies, I also had to make the same change to apr/build/apr_rules.mk:38.

---
Daniel Becroft


On Sat, Jan 15, 2011 at 8:45 AM, Daniel Becroft wrote:

> Hi,
>
> I've had some issues compiling Subversion and APR in my Ubuntu environment
> (the below output is done from /trunk - I haven't tried a 1.6.x branch yet).
>
> Running ./autogen.sh and ./configure work correctly, however I get the
> following error when running 'make':
>
> -- making all in apr
> make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr'
> make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr'
> sed 's,^\(location=\).*$,\1installed,' < apr-1-config > apr-config.out
> sed 's,^\(apr_build.*=\).*$,\1/usr/local/apr/build-1,' < build/
> apr_rules.mk > build/apr_rules.out
> make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr'
> make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr'
> -- completed all in apr
> -- making all in apr-util
> make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr-util'
> Making all in xml/expat
> make[2]: Entering directory
> `/home/djcbecroft/dev/subversion/apr-util/xml/expat'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory
> `/home/djcbecroft/dev/subversion/apr-util/xml/expat'
> make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr-util'
> /bin/bash /libtool --silent --mode=compile gcc -g -O2 -pthread
> -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
> -I/home/djcbecroft/dev/subversion/apr-util/include
> -I/home/djcbecroft/dev/subversion/apr-util/include/private
> -I/home/djcbecroft/dev/subversion/apr/include
> -I/home/djcbecroft/dev/subversion/apr-util/xml/expat/lib  -o
> buckets/apr_brigade.lo -c buckets/apr_brigade.c && touch
> buckets/apr_brigade.lo
> /bin/bash: /libtool: No such file or directory
> make[2]: *** [buckets/apr_brigade.lo] Error 127
> make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util'
> make: *** [external-all] Error 1
>
> After investigation, it seems that the path for LIBTOOL was defined
> incorrectly. I had to change apr-util/build/rules.mk:38 from:
>
> LIBTOOL=$(SHELL) $(top_builddir)/libtool
> to
> LIBTOOL=$(SHELL) $(apr_builddir)/libtool
>
> I'm unfamiliar with how the configure scripts work, so I'm not sure if this
> is a problem with the SVN scripts, APR scripts, or my system itself. If it's
> one of the first two, then I'll report it to the appropriate list. Can
> anyone provide any guidance?
> ---
> Daniel Becroft
>

Re: Trival merge of big text file: Dismal performance, 540x faster if binary.

[Johan Corveleyn]

On Fri, Jan 14, 2011 at 3:53 PM, krueger, Andreas (Andreas Krüger,
DV-RATIO)  wrote:
> Hello, Johan and all,
>
> first, for the record, here is another comparison between
> binary and text merge performance, this time with the files
> generated by my script (repeated below):
>
> Binary merge took 3.56 seconds, text merge took 3:45:45.202 hours.
> In this particular case, binary merge performance was 3805 times
> faster than text merge performance.
>
>
>
>> Textual merging in svn makes use of a variant of the standard diff
>> algorithm, namely diff3.  Just a couple of days ago, I finally
>> succeeded in making diff3 take advantage of ... performance
>> improvements ... .
>
> Good news! Excellent! Thank you!
>
> But... does this relate to my problem?
>
> The improved diff3 will give a nice performance improvement in the
> *general* case.
>
> I certainly want that improvement!
>
>
> Another nice performance improvement of a factor of several hundreds
> (or thousands) could be obtained for big files in the *trivial* case,
> if SVN didn't diff3 at all, but simply copied the result.
>
> I also want this other improvement!
>
>
> Finally:
>
> SVN already contains the intelligence needed to find out whether a
> merge is trivial or not.  For, in the binary case, the trivial merges
> are precisely the ones that SVN knows how to do.
>
>
> Johan (or whoever else), please kindly enlighten me, should I be
> missing something!

Ok, after rereading this thread, I'm starting to understand what you
mean: why would "merge" perform an expensive diffing algorithm while
it can just be 100% sure that it can simply copy the contents from the
source to the target (because the target file has not had any changes
since it was branched)?

I think it's a good suggestion, but I can't really comment more on
(the feasibility of) it, because I'm not that familiar with that part
of the codebase. I've only concentrated on the diff algorithm itself
(and how it's used by "svn diff" and "svn merge" (for text files)).
Maybe someone else can chime in to comment on that?

Of course, if there would be any change to the target file, it
wouldn't be a trivial merge (copy contents) anymore, so you would
immediately fallback to the very expensive case. But I agree that's
hardly a reason not to take the shortcut when you can...

A couple more thoughts on the diff-side of the story:
- Your perl script presents an extremely hard case for the diff
algorithm, because:
* Files A and B differ in each and every one of the 100 lines (so
my prefix/suffix scanning optimization will not help at all).
* All lines in each file are also unique inside the file (this makes
it more expensive).
* Most lines have identical lengths as other lines (also makes it more
expensive).
* The lines are very short (the diff algorithm is mainly proportional
with the number of lines).

These things are very atypical when you compare with real-world
examples. Usually there is some identical part at the beginning and/or
the end, and lines vary a lot in length. If there is a significant
portion of identical lines at the beginning and/or the end, the
optimizations in the diff-optimizations-bytes branch will help a lot.

- Interestingly, GNU diff calculates the diff between these files in 7
seconds on my machine. But if I give it the option '--minimal', it
also runs for hours (started it 2 hours ago; it's still running).

- Can you try the merge on your original example (big.xml) with the
option -x-b (ignore changes in amount of whitespace)? Just to know if
it would make a difference. In my tests this made diff *much* faster,
so I'm guessing the same for merge. Of course, this depends entirely
on the example data (won't help a bit for the perl-generated files
(will be slowed down even more)).

Cheers,
-- 
Johan

Re: SVN 1.6.15 checkout fails on particular file

[Daniel Shahaf]

KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800:
> > -Original Message-
> > From: David Huang [mailto:k...@azeotrope.org]
> > Sent: Friday, January 14, 2011 1:29 PM
> > To: KARR, DAVID (ATTSI)
> > Cc: users@subversion.apache.org
> > Subject: Re: SVN 1.6.15 checkout fails on particular file
> > 
> > 
> > On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
> > > I then looked at the full local path this file would represent, and
> > the entire path is 260 characters long.  I would think if there's any
> > threshold, it would be at 255, not 259.
> > >
> > > Any idea what's going on here?
> > 
> > The usual maximum path length limit on Windows is indeed 259 (or 260
> if
> > you count the terminating NUL): See the "Maximum Path Length
> > Limitation" section of http://msdn.microsoft.com/en-
> > us/library/aa365247%28v=vs.85%29.aspx
> 
> Hmm, then Eclipse/Subversion must be doing something special to avoid
> this problem.  My resulting paths in my existing projects checked out in
> Eclipse are quite a bit longer than 259 characters.

IIRC, it's use absolute paths instead of relative paths.

RE: SVN 1.6.15 checkout fails on particular file

[KARR, DAVID (ATTSI)]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: Friday, January 14, 2011 4:20 PM
> To: KARR, DAVID (ATTSI)
> Cc: David Huang; users@subversion.apache.org
> Subject: Re: SVN 1.6.15 checkout fails on particular file
> 
> KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800:
> > > -Original Message-
> > > From: David Huang [mailto:k...@azeotrope.org]
> > > Sent: Friday, January 14, 2011 1:29 PM
> > > To: KARR, DAVID (ATTSI)
> > > Cc: users@subversion.apache.org
> > > Subject: Re: SVN 1.6.15 checkout fails on particular file
> > >
> > >
> > > On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
> > > > I then looked at the full local path this file would represent,
> and
> > > the entire path is 260 characters long.  I would think if there's
> any
> > > threshold, it would be at 255, not 259.
> > > >
> > > > Any idea what's going on here?
> > >
> > > The usual maximum path length limit on Windows is indeed 259 (or
> 260
> > if
> > > you count the terminating NUL): See the "Maximum Path Length
> > > Limitation" section of http://msdn.microsoft.com/en-
> > > us/library/aa365247%28v=vs.85%29.aspx
> >
> > Hmm, then Eclipse/Subversion must be doing something special to
avoid
> > this problem.  My resulting paths in my existing projects checked
out
> in
> > Eclipse are quite a bit longer than 259 characters.
> 
> IIRC, it's use absolute paths instead of relative paths.

I'm not sure what you mean.  You're saying that Subversive in Eclipse is
referencing absolute paths, but using the command line client is using
relative paths?  Assuming that's the distinction, is there some way I
could use the command-line client in a different way that might avoid
this problem?

Re: Trival merge of big text file: Dismal performance, 540x faster if binary.

[Daniel Shahaf]

Johan Corveleyn wrote on Fri, Jan 14, 2011 at 23:52:10 +0100:
> Ok, after rereading this thread, I'm starting to understand what you
> mean: why would "merge" perform an expensive diffing algorithm while
> it can just be 100% sure that it can simply copy the contents from the
> source to the target (because the target file has not had any changes
> since it was branched)?
> 
> I think it's a good suggestion, but I can't really comment more on
> (the feasibility of) it, because I'm not that familiar with that part
> of the codebase. I've only concentrated on the diff algorithm itself
> (and how it's used by "svn diff" and "svn merge" (for text files)).
> Maybe someone else can chime in to comment on that?

In other words, merging changes from file.c@BRANCH to trunk should
detect that file@trunk and file@BRANCH@BRANCH-CREATION are the same
node-revision?

I don't know whether it does that... but giving the question more
visibility (as opposed to burying it in the middle of a paragraph on
users@) might help you get an answer. :-)

Re: SVN 1.6.15 checkout fails on particular file

[Daniel Shahaf]

KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 16:31:04 -0800:
> > -Original Message-
> > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> > Sent: Friday, January 14, 2011 4:20 PM
> > To: KARR, DAVID (ATTSI)
> > Cc: David Huang; users@subversion.apache.org
> > Subject: Re: SVN 1.6.15 checkout fails on particular file
> > 
> > KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800:
> > > > -Original Message-
> > > > From: David Huang [mailto:k...@azeotrope.org]
> > > > Sent: Friday, January 14, 2011 1:29 PM
> > > > To: KARR, DAVID (ATTSI)
> > > > Cc: users@subversion.apache.org
> > > > Subject: Re: SVN 1.6.15 checkout fails on particular file
> > > >
> > > >
> > > > On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote:
> > > > > I then looked at the full local path this file would represent,
> > and
> > > > the entire path is 260 characters long.  I would think if there's
> > any
> > > > threshold, it would be at 255, not 259.
> > > > >
> > > > > Any idea what's going on here?
> > > >
> > > > The usual maximum path length limit on Windows is indeed 259 (or
> > 260
> > > if
> > > > you count the terminating NUL): See the "Maximum Path Length
> > > > Limitation" section of http://msdn.microsoft.com/en-
> > > > us/library/aa365247%28v=vs.85%29.aspx
> > >
> > > Hmm, then Eclipse/Subversion must be doing something special to
> avoid
> > > this problem.  My resulting paths in my existing projects checked
> out
> > in
> > > Eclipse are quite a bit longer than 259 characters.
> > 
> > IIRC, it's use absolute paths instead of relative paths.
> 
> I'm not sure what you mean.  You're saying that Subversive in Eclipse is
> referencing absolute paths, but using the command line client is using
> relative paths?  Assuming that's the distinction, is there some way I
> could use the command-line client in a different way that might avoid
> this problem?

Pass absolute paths to the cmdline client when you invoke it :)

(svn 1.7 will use absolute paths internally)

Re: SVN 1.6.15 checkout fails on particular file

[David Huang]

On Jan 14, 2011, at 6:31 PM, KARR, DAVID (ATTSI) wrote:
> I'm not sure what you mean.  You're saying that Subversive in Eclipse is
> referencing absolute paths, but using the command line client is using
> relative paths?  Assuming that's the distinction, is there some way I
> could use the command-line client in a different way that might avoid
> this problem?


The SVN library used by the commandline client uses the Apache Portable Runtime 
library (apr), which IIRC, uses the special "\\?\" prefix when needed to 
support long pathnames. I don't know much about Subversive, but perhaps it 
doesn't do that trick?

P.S. Your mail server (att.com?) doesn't seem to like me :( At least my first 
email to you was bounced back by MessageLabs saying there was something wrong 
with the content.
-- 
Name: Dave Huang |  Mammal, mammal / their names are called /
INet: k...@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++

clearing svn conflict accept options

[Carlos S]

I had selected an option to 'accept their copy always' during svn
conflict. How do I remove/clear this option? Also, is there any guide
that explains these conflict actions/options?

Thanks,
CS.