Re: mergeinfo clean

[Ulrich Eckhardt]

Curiosity up front: I couldn't find an encoding that displayed the 
letter/accent between the 'i' and 's' in your name, I only get a box there. 
What encoding are you using and what should be there?


On Tuesday 25 January 2011, Piotr Kabaciński wrote:
> Working with svn project for longer time causes growth of mergeinfo
> property and very unreadable diffs between commits.

There is one good rule about merging, and that is to always merge to the same 
root directory of the project. Once parts of a project are merged separately, 
they retain their own svn:mergeinfo property, and every merge to the root 
then changes these, too, even if nothing on that child item was changed. This 
of course requires that you don't mix different changes in a single commit, 
but that is a best practice anyway.

> SVN with every commit updates mergeinfo value what is needed to keep
> tracking merges, but sometimes updating this value is no longer needed
> because merged branch no longer exists and i do not need to remember
> about it.
> I created a program that checks every mergeinfo property and if listed
> path doesn't exists it is removed.
> What do you think about this solution? Do you think it is safe?

You could nuke the whole svn:mergeinfo without SVN itself falling apart. 
However, some things won't work "right" automatically any more. In particular 
SVN won't ignore requests to merge things that were already merged, because 
it doesn't know about them. Now, the chance of someone merging from a deleted 
branch (which is of course still possible!) are small, so I guess your method 
is safe.

Cheers!

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Copy with externals, then commit fails

[Ryno Changuion]

I tried to create a new branch of a trunk that had some svn:externals
definition. 

In particular, it pointed to a file.

 

I.e.

/somewhere/a.txt@4 a.txt

 

I used

svn copy svn://server/trunk branch

And the output from that was the usual stuff including

E  a.txt (indicating an externals file).

 

svn stat had the following output:

 +X   a.txt

Of course, the plus means "with history". 

 

After this, I could not do a commit. The commit failed with a message:

svn: File not found: revision 4, path '/trunk/a.txt'

 

My suspicion is that due to the fact that the file has history
associated

with it, the commit tries to commit a file that it shouldn't be
committing.

Besides, I didn't want to add a.txt to my branch, I still wanted it to
come 

from the original externals definition. Is it a bug that svn copy adds 

history info to an external file?

 

Anyway, I did manage to work around the problem by using

svn copy --ignore-externals svn://server/trunk branch

 

 

 

Re: directory problem on 'svn ci'

[Andreas Wolff]

Daniel Shahaf wrote:

What version did you upgrade to 1.6.15 from?


From a 1.6.4 installation.


Are there any svn-commit.tmp, svn-commit.2.tmp preexisting?


No, there are none. I double checked and deleted all *.tmp in the 
concerned directories.



What happens if you use the following script as your editor:

#!/bin/sh
echo "hi">  $1


That would be quite hard to do, as I'm experiencing this problem on a 
windows machine. Introducing cygwin to the problem probably won't be of 
much help.

Understanding what you are driving at, i used this Batch command script:

@echo off
echo Path test > %1

It yields the exact same result as the earlier mentioned true editors do.
svn-commit.tmp ends up one directory up from CWD and the 'svn 
ci'-process keeps asking me:


Log message unchanged or not specified
(a)bort, (c)ontinue, (e)dit:

Greetings,
Andreas

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Stefan Sperling]

On Tue, Jan 25, 2011 at 12:51:12PM -0700, Donner, Sean P wrote:
> I'm attempting to setup svnserve with SASL support on my Slackware 13.1 
> server and after
> some trial and error I'm able to get it to work with the configuration listed 
> at the end of this
> post.
> 
> You'll notice that the output of sasldblistusers2 shows my test user as 
> having both an
> encrypted cmusaslsecretOTP password as well as a plain text userPassword. 
> i.e., if I were to
> run the command ‘strings /etc/sasl2/my_sasldb’ I would see the test users' 
> password in
> plaintext. These two password entries were created with the following 
> subversion-book
> recommended command:
> 
> saslpasswd2 -c -f /etc/sasl2/my_sasldb -u myrepo test
> 
> After reading man saslpasswd2 I see the following option:
> 
> "-n Don't set the plaintext userPassword property for the user. Only 
> mechanism-specific
> secrets will be set (e.g. OTP, SRP)"
> 
> This is exactly what I want to do, suppress the plain text password and only 
> use the
> mechanism-specific secret (OTP in my case). So I clear out 
> /etc/sasl2/my_sasldb and rerun
> saslpasswd2 as:
> 
> saslpasswd2 -n -c -f /etc/sasl2/my_sasldb -u myrepo test
> 
> I then follow it up with a sasldblistusers2 and I see:
> 
> $ sasldblistusers2 -f /etc/sasl2/my_sasldb
> test@myrepo: cmusaslsecretOTP
> 
> Perfect! Now I have only encrypted passwords in my sasldb only neither 
> the Linux svn
> client nor the Windows TortoiseSVN client can connect to my repo anymore. 
> They both
> present me with an endless loop of user/pass challenge. As soon as I rerun 
> saslpasswd2
> without the '-n' flag, everything works again.
> 
> So, what’s the point of svnserve supporting SASL if my sasldb must store its 
> passwords in
> plaintext to work?

It's because of how CramMD5 works.

"The server needs access to the users' plain text passwords."
http://en.wikipedia.org/wiki/CRAM-MD5

Stefan

Re: directory problem on 'svn ci'

[Stefan Sperling]

On Tue, Jan 25, 2011 at 08:28:08PM -0600, Ryan Schmidt wrote:
> 
> >> I _know_, by sheer evidence of the svn-commit.tmp file being  
> >> "physically" there, that it is created one directory level above where  
> >> it was used to be created!
> > 
> 
> FWIW, on my Mac OS X installation (Mac OS X 10.6.6, SVN 1.6.15), I also 
> notice the svn-commit.tmp is created one directory up, but that appears to be 
> normal for Subversion (now anyway; not sure what used to be normal), and 
> works fine for me.
> 

Can someone take the time to confirm if this has changed from earlier
versions, and if so, in which version this changed?

Thanks,
Stefan

Question about branching, merging and reintegrating

[Christer Edvartsen]

I have a question about the following scenario:

I have /trunk and a branch made from trunk that I'm working on (let's call
it /branches/x). I also have a branch created from x (let's call that
/branches/y).

When someone has made a change to trunk i do svn merge ^/trunk in branch
x, and svn merge ^/branches/x in branch y which works as expected.

Is it OK to reintegrate branch x in trunk BEFORE finishing branch y? It
looks like subversion is smart enough to handle this, but before I do too
much work using the current setup I am interested if anyone else has tried
this.

After reintegrating branch x I guess I can just merge branch y directly
with trunk and later reintegrate y into trunk.

Does anyone know if this will work as expected?


-- 
Christer Edvartsen
http://cogo.wordpress.com/

Apache wedging over https

[Neil Bird]

  I should probably go to the Apache-specific site for this, but I thought 
I'd ask here in case anyone else has seen the like.


  We have Apache running as a Subversion server on a Solaris 10 box.  It's 
all working a treat.


  Now, we have the server explicitly only talking SVN over https, and we 
use that exclusively.  The http I/F only give a dummy "it's working" page.


  Every so often¹, SVN stops responding;  all [https, not just svn] 
requests just hang.  I accidentally discovered, while trying various 
diagnoses, that requesting said dummy page over http unfreezes the server.


  This has happened a number of times now, and every time without fail, 
going to http://oursvnserver/ to get the dummy page immediately unfreezes 
all current requests.  I see no errors in the Apache log for the times when 
this occurs.


  Has anyone else seen anything like this?


¹ - we seem to have come up with a near-failure case that causes this almost 
every time, which I'll post about separately, but I'm not sure it's 
relevant.  (It's when trying to co a dir. with 5000+ files in onto a Windows 
box whose virus scanner goes berserk trying to monitor the activity).


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Checkout really slow in Windows with lots of files in one directory

[Neil Bird]

  We have a graphics-oriented code-base that's auto-generated and has >5000 
source files in one directory.  While I can check this out OK on Linux, 
we're seeing an unusable slow-down on Windows XP (NTFS), both using Tortoise 
directly, and as a test on Linux with the Windows drive mapped over CIFS.


  The checkout starts sensibly enough, but then gets steadily slower and 
slower and slower, to the point were we're not sure it'd actually ever end.


  I know that there's a negative speed difference on NTFS, and that 1.7's 
WC-NG might make this better, but this is getting near-logarithmically slower.


  Is that to be expected, or at least known about?


  (we're going to jigger the files around into sep. directories to get the 
individual counts down;  I expect that to help in this instance).


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Checkout really slow in Windows with lots of files in one directory

[Campbell Allan]

On Wednesday 26 Jan 2011, Neil Bird wrote:
>We have a graphics-oriented code-base that's auto-generated and has
> >5000 source files in one directory.  While I can check this out OK on
> Linux, we're seeing an unusable slow-down on Windows XP (NTFS), both using
> Tortoise directly, and as a test on Linux with the Windows drive mapped
> over CIFS.
>
>The checkout starts sensibly enough, but then gets steadily slower and
> slower and slower, to the point were we're not sure it'd actually ever end.
>
>I know that there's a negative speed difference on NTFS, and that 1.7's
> WC-NG might make this better, but this is getting near-logarithmically
> slower.
>
>Is that to be expected, or at least known about?
>
>
>(we're going to jigger the files around into sep. directories to get the
> individual counts down;  I expect that to help in this instance).

That is what I recall from previous reports. I originally was going to see if 
anything could be done as it sounds like a classic problem of a linear 
search/sort over a growing list. The big unanswered question was where was 
this list.

If the code is auto generated would it be possible to generate it for each 
build? That's what we typically do where I work. Anything that is generated 
is not committed. A bad example would be to say I have java source code, I 
don't need to commit the compiled byte code too or jars too.

-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

Re: Checkout really slow in Windows with lots of files in one directory

[Campbell Allan]

On Wednesday 26 Jan 2011, Campbell Allan wrote:
> On Wednesday 26 Jan 2011, Neil Bird wrote:
> >We have a graphics-oriented code-base that's auto-generated and has
> >
> > >5000 source files in one directory.  While I can check this out OK on
> >
> > Linux, we're seeing an unusable slow-down on Windows XP (NTFS), both
> > using Tortoise directly, and as a test on Linux with the Windows drive
> > mapped over CIFS.
> >
> >The checkout starts sensibly enough, but then gets steadily slower and
> > slower and slower, to the point were we're not sure it'd actually ever
> > end.
> >
> >I know that there's a negative speed difference on NTFS, and that
> > 1.7's WC-NG might make this better, but this is getting
> > near-logarithmically slower.
> >
> >Is that to be expected, or at least known about?
> >
> >
> >(we're going to jigger the files around into sep. directories to get
> > the individual counts down;  I expect that to help in this instance).
>
> That is what I recall from previous reports. I originally was going to see
> if anything could be done as it sounds like a classic problem of a linear
> search/sort over a growing list. The big unanswered question was where was
> this list.
>
> If the code is auto generated would it be possible to generate it for each
> build? That's what we typically do where I work. Anything that is generated
> is not committed. A bad example would be to say I have java source code, I
> don't need to commit the compiled byte code too or jars too.

I should have added I'm not a subversion dev, just a curious interested party 
as a lot of my colleagues were still on windows at the time I first 
encountered this.

-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

Re: Checkout really slow in Windows with lots of files in one directory

[Ryan Schmidt]

On Jan 26, 2011, at 08:28, Neil Bird wrote:

>  We have a graphics-oriented code-base that's auto-generated and has >5000 
> source files in one directory.  While I can check this out OK on Linux, we're 
> seeing an unusable slow-down on Windows XP (NTFS), both using Tortoise 
> directly, and as a test on Linux with the Windows drive mapped over CIFS.
> 
>  The checkout starts sensibly enough, but then gets steadily slower and 
> slower and slower, to the point were we're not sure it'd actually ever end.
> 
>  I know that there's a negative speed difference on NTFS, and that 1.7's 
> WC-NG might make this better, but this is getting near-logarithmically slower.
> 
>  Is that to be expected, or at least known about?

If, as you posted in your other thread, there is an on-access virus scanner on 
this PC, then that could also be significant. Try turning off the virus scanner 
or excluding the directory where you're doing this checkout.

Re: directory problem on 'svn ci'

[Ryan Schmidt]

On Jan 26, 2011, at 05:07, Stefan Sperling wrote:
> On Tue, Jan 25, 2011 at 08:28:08PM -0600, Ryan Schmidt wrote:
>> 
 I _know_, by sheer evidence of the svn-commit.tmp file being  
 "physically" there, that it is created one directory level above where  
 it was used to be created!
>> 
>> FWIW, on my Mac OS X installation (Mac OS X 10.6.6, SVN 1.6.15), I also 
>> notice the svn-commit.tmp is created one directory up, but that appears to 
>> be normal for Subversion (now anyway; not sure what used to be normal), and 
>> works fine for me.
> 
> Can someone take the time to confirm if this has changed from earlier
> versions, and if so, in which version this changed?

I tested 1.6.15, 1.6.4, and 1.6.0, and they all behaved the same, which was:

If I have a working copy /path/to/wc and I am in that directory and I commit, 
svn-commit.tmp is created in /path/to/wc.

If I am in a subdirectory of that working copy and I commit, svn-commit.tmp is 
created in the parent directory. For example, if I am in /path/to/wc/foo/bar 
and I commit, svn-commit.tmp is created in /path/to/wc/foo.

I'm still unclear what problem this behavior is perceived to cause.

Note I did all tests with apr 1.4.2 and apr-util 1.3.10. Perhaps this is an apr 
or apr-util issue and trying earlier versions of those would produce different 
results. Andreas, do you know what versions of apr and apr-util you have now, 
and what versions you had before?

Re: Checkout really slow in Windows with lots of files in one directory

[Andy Levy]

On Wed, Jan 26, 2011 at 09:28, Neil Bird  wrote:
>
>  We have a graphics-oriented code-base that's auto-generated and has >5000
> source files in one directory.  While I can check this out OK on Linux,
> we're seeing an unusable slow-down on Windows XP (NTFS), both using Tortoise
> directly, and as a test on Linux with the Windows drive mapped over CIFS.
>
>  The checkout starts sensibly enough, but then gets steadily slower and
> slower and slower, to the point were we're not sure it'd actually ever end.
>
>  I know that there's a negative speed difference on NTFS, and that 1.7's
> WC-NG might make this better, but this is getting near-logarithmically
> slower.
>
>  Is that to be expected, or at least known about?

It's known and oft-lamented. NTFS just doesn't handle this scenario
well - it's probably one of the reasons FSFS sharding was introduced
(I'm speculating a bit here).

How's the checkout performance with a command-line client on that XP
box? It could also be your on-access virus scanner, and testing w/ the
command-line client may help diagnose that.

Re: Checkout really slow in Windows with lots of files in one directory

[Stefan Sperling]

On Wed, Jan 26, 2011 at 09:43:15AM -0500, Andy Levy wrote:
> NTFS just doesn't handle this scenario
> well - it's probably one of the reasons FSFS sharding was introduced
> (I'm speculating a bit here).

IIRC that is correct.
Sharding was introduced to prevent long-running readdir() system calls.
It is on the server though and does not affect client behaviour.

So while the client might suffer similar issues with directories with
many files in it, a virus scanner is much more likely to cause notable
delays on Windows. Subversion creates temporary files and then moves
them into place. Virus scanners don't interact well with that.
Especially since it's impossible to rename open files on Windows.

Don't run virus scanners on working copies.
If you want to check for viruses in the repository, use a designated
working copy and trigger a scan of changed files from the post-commit hook.

RE: Checkout really slow in Windows with lots of files in one directory

[Echlin, Jamie]

>I know that there's a negative speed difference on NTFS, 
> and that 1.7's WC-NG might make this better, but this is 
> getting near-logarithmically slower.

There's good information about NTFS wrt subversion here:
http://superuser.com/questions/15192/bad-ntfs-performance

I found FAT was 10-20x faster than NTFS for the lock/unlock working copy
operation, but I never saw a case where it was logarithmically slow or
appeared to get slower as it went on.

It's easy to test this. Install ImDisk from here:
http://www.ltr-data.se/opencode.html/#ImDisk which is very
straightforward (no reboot), and create two virtual disks, format one as
ntfs and one as FAT32. 

Then compare the timings between the three (the third being the physical
disk).

The differences are magnified when the amount of actual work to do is
small compared to the time required for the lock/unlock operation, eg an
svn update when nothing has changed on the server.

jamie

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

RE: Checkout really slow in Windows with lots of files in one directory

[Echlin, Jamie]

On second thoughts my previous mail is related to when you have a
massive number of sub-dirs in your working copy. I didn't properly read
you mail, sorry.

Perhaps your Master File Table is fragmented... In which case a defrag
might help. 

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

Precautions for Subversion

[Waseem Bokhari]

Hola Experts
 
   I have Windows environment for Subversion.
 
Server - Visual SVN Enterprise Edition with Windows 2003 Enterprise Edition
Clients- XP Mostly and windows 2008 a few. Tortoise SVN.
 
Antivirus as well.
 
Is there any need to take precautions as in our organization WE WILL HAVE TO
RUN antivirus on 3 days a week. Is it would take any impact on Our windows
machines in presence of Subversion/Tortoise SVN OR Visual SVN.
 
Please advice accordingly.
 
GraciasJ
 
 
 
 
 Cheers!
 
cid:image001.jpg@01CA74D6.C3770120
 
Waseem Bokhari I Configurations and Release Management 
NetSol Technologies (NasdaqCM: NTWK)
Tel: +92 42 111448800 Ext: 346 Mob: +92 321 4294926
  waseem.bokha...@netsoltech.com
 www.netsoltech.com
 
 


DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely 
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email 
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar 
expressions, identify forward looking statements, but their absence does not 
mean that the 
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of 
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained 
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and 
assumptions that are difficult to predict. The company will not undertake to 
update any statements 
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses. 
Although the company has taken reasonable precautions to ensure no viruses are 
present in this 
email, the company does not accept responsibility for any loss or damage 
arising from the use of 
this email or attachment. Note: Please consider the environment before printing 
this e-mail. 
<>

Re: Checkout really slow in Windows with lots of files in one directory

[Johan Corveleyn]

On Wed, Jan 26, 2011 at 3:41 PM, Campbell Allan
 wrote:
>
> On Wednesday 26 Jan 2011, Neil Bird wrote:
>>    We have a graphics-oriented code-base that's auto-generated and has
>> >5000 source files in one directory.  While I can check this out OK on
>> Linux, we're seeing an unusable slow-down on Windows XP (NTFS), both using
>> Tortoise directly, and as a test on Linux with the Windows drive mapped
>> over CIFS.
>>
>>    The checkout starts sensibly enough, but then gets steadily slower and
>> slower and slower, to the point were we're not sure it'd actually ever end.
>>
>>    I know that there's a negative speed difference on NTFS, and that 1.7's
>> WC-NG might make this better, but this is getting near-logarithmically
>> slower.
>>
>>    Is that to be expected, or at least known about?
>>
>>
>>    (we're going to jigger the files around into sep. directories to get the
>> individual counts down;  I expect that to help in this instance).
>
> That is what I recall from previous reports. I originally was going to see if
> anything could be done as it sounds like a classic problem of a linear
> search/sort over a growing list. The big unanswered question was where was
> this list.
>
> If the code is auto generated would it be possible to generate it for each
> build? That's what we typically do where I work. Anything that is generated
> is not committed. A bad example would be to say I have java source code, I
> don't need to commit the compiled byte code too or jars too.

I seem to remember that this has something to do with the way the svn
client determines unique names for its temp files during such a
checkout. Something like: it first tries filename 'tmpfile1', if that
exists it tries 'tmpfile2', then 'tmpfile3', ... and so on. So if it's
checking out file number 5000, it first tries 4999 filenames that are
already in use, and only then comes to the conclusion that
'tmpfile5000' is the unique filename it should use. That could explain
the 'ever slowing down' behavior that you see, when more and more
files in the same dir get checked out.

I'm not entirely sure, but I vaguely remember that this came up as a
thread on the users list or on the dev list (but unfortunately, I
can't find it right now). I also seem to remember that this was fixed
on trunk, so should be much better in 1.7 (by choosing the unique
filenames randomly (and then checking if it already exists), instead
of with an incrementing number). Again, I can't find the commit or
dev-list discussion, but it's floating in the back of my head
somewhere...

If I have more time, I'll try to search the archives some more.

In the meantime (while we're waiting for 1.7 :-)): splitting it up
into multiple directories seems like a good workaround...

Cheers,
-- 
Johan

Re: Precautions for Subversion

[Ulrich Eckhardt]

On Wednesday 26 January 2011, Waseem Bokhari wrote:
> I have Windows environment for Subversion.
>
> Server - Visual SVN Enterprise Edition with Windows 2003 Enterprise Edition
> Clients- XP Mostly and windows 2008 a few. Tortoise SVN.
>
> Antivirus as well.
>
> Is there any need to take precautions as in our organization WE WILL HAVE
> TO RUN antivirus on 3 days a week. Is it would take any impact on Our
> windows machines in presence of Subversion/Tortoise SVN OR Visual SVN.

See the recent thread "Checkout really slow in Windows..". For the server 
side, there are also a handful of operations per commit and each of them is 
slowed down. However, it's not thousands of operations like in a working copy 
and the slowdown is probably bearable.

Further, the actual client/server (vanilla SVN, TSVN, Visual SVN) doesn't 
matter. They are all based on the same code and show the same performance 
characteristics.


Good luck!

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Checkout really slow in Windows with lots of files in one directory

[Neil Bird]

Around about 26/01/11 14:41, Campbell Allan typed ...

If the code is auto generated would it be possible to generate it for each
build?


  Interesting question;  I shall have to ask it.  I *think*, in actual 
fact, that it was *originally* generated, but has since been tweaked 
manually or with scripts.  Or it may have been done in an 'alien' 
environment (Cygwin or Linux) to the Windows-only build process.


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Checkout really slow in Windows with lots of files in one directory

[Neil Bird]

Around about 26/01/11 14:43, Andy Levy typed ...

It's known and oft-lamented. NTFS just doesn't handle this scenario
well - it's probably one of the reasons FSFS sharding was introduced
(I'm speculating a bit here).


  This is stuff that's currently in SourceSafe, which doesn't exhibit any 
obvious issues (well, apart from the obvious :) ), so I can't blame NTFS 
just for not handling the sheer volume of files.




How's the checkout performance with a command-line client on that XP
box? It could also be your on-access virus scanner, and testing w/ the
command-line client may help diagnose that.


  I tested Linux command-line over a CIFS mount to the NTFS drive, on a box 
for which that directory was excluded for on-access scan, so the virus 
scanner isn't in the loop.  Could be some other IT spyware^H^H^H^H^H^H 
logging software, though.  But there's nothing using excess CPU in that case.


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Checkout really slow in Windows with lots of files in one directory

[Neil Bird]

Around about 26/01/11 15:24, Stefan Sperling typed ...

Don't run virus scanners on working copies.
If you want to check for viruses in the repository, use a designated
working copy and trigger a scan of changed files from the post-commit hook.


  The virus scanner excludes this particular directory on my box, which 
also suffers the slow-down.


  When we do the checkout via tortoise, tortoise sits at 100% CPU load, and 
I don't see anything else fighting it for time.


  I've not monitored the load on the Windows svn command-line.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

Re: Checkout really slow in Windows with lots of files in one directory

[Neil Bird]

Around about 26/01/11 15:30, Echlin, Jamie typed ...

Perhaps your Master File Table is fragmented... In which case a defrag
might help.


  We see exactly the same problem on two diff. Windows PCs, but I'll give 
ImDisk a bash in the morning for the sake of experimentation.


  And I recently defreagged mine.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

RE: Checkout really slow in Windows with lots of files in one directory

[Echlin, Jamie]

>We see exactly the same problem on two diff. Windows PCs, 
> but I'll give ImDisk a bash in the morning for the sake of 
> experimentation.

Have you tried Process Explorer? Look at the stack trace of one of the
events when it's started slowing down. Make sure the symbol server is
configured. That can be very helpful...

Nothing funny with NTFS ACLs? Is the ACL it's inheriting sensible?
Trying on a FAT virtual disk would help rule that out.

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

Re: Windows over linux

[David Darj]

On 2011-01-26 03:37, Ryan Schmidt wrote:

On Jan 25, 2011, at 02:43, Oliver Marshall wrote:

If you are equally proficient with all OSes and have no preference, you might 
want to choose a UNIX-like OS, because many hook script examples will be 
written assuming that is what you are running. Some may be written in Bash, for 
example. If you are proficient in writing scripts for windows (batch scripts, 
or perl, ruby, php, python, etc.) and you feel confident in your ability to 
translate a Bash script into another language for use on Windows, or if you 
don't plan to use hook scripts, then using Windows should be no problem.

Hooks are not necessarily scripts.

If you're not comfortable in writing scripts at all, you can use your 
favorite programming environment an write the hook "scripts" there.
In my department we have a couple of hooks written in C#, and we serve 
our repository through Apache on Windows 2008.

(Of cause these hooks are revision controlled in the svn-repository itself).

So, to sum up  the last couple of post, use the environment you and your 
company are most comfortable with.


/David

Re: Precautions for Subversion

[Andy Levy]

On Wed, Jan 26, 2011 at 10:46, Waseem Bokhari
 wrote:
>
> Hola Experts
>
>
>
>    I have Windows environment for Subversion.
>
>
>
> Server - Visual SVN Enterprise Edition with Windows 2003 Enterprise Edition
>
> Clients- XP Mostly and windows 2008 a few. Tortoise SVN.
>
> Antivirus as well.

>
> Is there any need to take precautions as in our organization WE WILL HAVE TO 
> RUN antivirus on 3 days a week. Is it would take any impact on Our windows 
> machines in presence of Subversion/Tortoise SVN OR Visual SVN.
>

What antivirus are you using? Some are better than others.

If your AV can be configured to not scan .svn directories, it will
help your WC performance tremendously.

There isn't much point in scanning the repository database, as the
file contents aren't "readable" - an EXE put into the repository
doesn't look like an EXE if you look at the contents of the repository
directly on disk.

>
> DISCLAIMER: This e-mail and any file transmitted with it are confidential and 
> intended solely for the use of the addressee. If you are not the intended 
> recipient, you are hereby advised that any dissemination, distribution or 
> copy of this email or its attachments is strictly prohibited. If you have 
> received this email in error, please immediately notify us by return email 
> and destroy this email message and its attachments. This communication may 
> contain forward-looking statements relating to the development of NetSol 
> Technologies' products and services and future operations. The words 
> "believe," "expect," "anticipate," "intend," variations of such words, and 
> similar expressions, identify forward looking statements, but their absence 
> does not mean that the statement is not forward-looking. Views and opinions 
> contained herein are those of the author of this email and do not necessarily 
> represent those of NetSol Technologies. Statements contained herein are not 
> guarantees of future performance and are subject to certain risks, 
> uncertainties and assumptions that are difficult to predict. The company will 
> not undertake to update any statements contained herein.
>
> WARNING: The recipient should check this email and any attachment for the 
> presence of viruses. Although the company has taken reasonable precautions to 
> ensure no viruses are present in this email, the company does not accept 
> responsibility for any loss or damage arising from the use of this email or 
> attachment. Note: Please consider the environment before printing this e-mail.


Disclaimers such as this on messages posted to PUBLIC mailing lists
are pointless.

Re: Checkout really slow in Windows with lots of files in one directory

[Thorsten Schöning]

Guten Tag Neil Bird,
am Mittwoch, 26. Januar 2011 um 18:02 schrieben Sie:

>When we do the checkout via tortoise, tortoise sits at 100% CPU load, and
> I don't see anything else fighting it for time.

This could be the cache processing the events from the shell about
updated and new files. I often see this for some seconds when I just
enter my larger working copies without updating out or else.

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: directory problem on 'svn ci'

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, Jan 26, 2011 at 09:12:44 -0600:
> If I am in a subdirectory of that working copy and I commit,
> svn-commit.tmp is created in the parent directory. For example, if
> I am in /path/to/wc/foo/bar and I commit, svn-commit.tmp is created in
> /path/to/wc/foo.

The directory of the tempfile depends on the invocation.  IIRC it's
different for 'cd wc/sub/dir/; svn ci foo' and 'svn ci wc/sub/dir/' and
'svn ci wc/sub/dir/foo'.

Re: directory problem on 'svn ci'

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, Jan 26, 2011 at 09:12:44 -0600:
> Note I did all tests with apr 1.4.2 and apr-util 1.3.10. Perhaps this

Just curious, why mix apr/apr-util of different minor (1.%d) versions?

> is an apr or apr-util issue and trying earlier versions of those would
> produce different results. Andreas, do you know what versions of apr
> and apr-util you have now, and what versions you had before?

Re: directory problem on 'svn ci'

[Stefan Sperling]

On Wed, Jan 26, 2011 at 08:21:12PM +0200, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Wed, Jan 26, 2011 at 09:12:44 -0600:
> > Note I did all tests with apr 1.4.2 and apr-util 1.3.10. Perhaps this
> 
> Just curious, why mix apr/apr-util of different minor (1.%d) versions?

There is no apr-util 1.4.x. See http://apr.apache.org/

Stefan

Re: Checkout really slow in Windows with lots of files in one directory

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, Jan 26, 2011 at 17:15:40 +0100:
> If I have more time, I'll try to search the archives some more.

If it helps your code/mail grepping, I believe you're talking about 
svn_io_open_uniquely_named().

(I found it by doing `fgrep '.%' subversion/libsvn_subr/*c`.)

Re: mergeinfo clean

[Daniel Shahaf]

Ulrich Eckhardt wrote on Wed, Jan 26, 2011 at 09:52:06 +0100:
> Curiosity up front: I couldn't find an encoding that displayed the 
> letter/accent between the 'i' and 's' in your name, I only get a box there. 
> What encoding are you using and what should be there?

Shows fine here (small N with acute accent), and Vim tells me it's U+0144.

Re: Checkout really slow in Windows with lots of files in one directory

[Andy Levy]

On Wed, Jan 26, 2011 at 11:59, Neil Bird  wrote:
> Around about 26/01/11 14:43, Andy Levy typed ...
>>
>> It's known and oft-lamented. NTFS just doesn't handle this scenario
>> well - it's probably one of the reasons FSFS sharding was introduced
>> (I'm speculating a bit here).
>
>  This is stuff that's currently in SourceSafe, which doesn't exhibit any
> obvious issues (well, apart from the obvious :) ), so I can't blame NTFS
> just for not handling the sheer volume of files.

SourceSafe (last I knew) manages working copies differently.
Subversion downloads into a temp location inside .svn, then copies
that to the "real" location in .svn, then copies to the "visible"
working copy. There's a *lot* more I/O going on with Subversion.

Re: mergeinfo clean

[Piotr Kabaciński]

On 01/26/2011 07:47 PM, Daniel Shahaf wrote:

Ulrich Eckhardt wrote on Wed, Jan 26, 2011 at 09:52:06 +0100:

Curiosity up front: I couldn't find an encoding that displayed the
letter/accent between the 'i' and 's' in your name, I only get a box there.
What encoding are you using and what should be there?


Shows fine here (small N with acute accent), and Vim tells me it's U+0144.


Checking source of the message (header From) will tell you the truth - 
ISO-8859-2 (latin2).

btw, i was convinced i had utf8, until now :)

--
Piotr Kabacinski
a2Fib3Q=

Re: mergeinfo clean

[Piotr Kabaciński]

On 01/26/2011 09:52 AM, Ulrich Eckhardt wrote:

Working with svn project for longer time causes growth of mergeinfo
property and very unreadable diffs between commits.


There is one good rule about merging, and that is to always merge to the same
root directory of the project. Once parts of a project are merged separately,
they retain their own svn:mergeinfo property, and every merge to the root
then changes these, too, even if nothing on that child item was changed. This
of course requires that you don't mix different changes in a single commit,
but that is a best practice anyway.


Merging always to the same directory that is what i am trying to do. 
Unfortunately it doesn't work every time. I agree that project could be 
leaded wrong but (and again, unfortunately) i had to work with it and 
handle problems like this one :)




SVN with every commit updates mergeinfo value what is needed to keep
tracking merges, but sometimes updating this value is no longer needed
because merged branch no longer exists and i do not need to remember
about it.
I created a program that checks every mergeinfo property and if listed
path doesn't exists it is removed.
What do you think about this solution? Do you think it is safe?


You could nuke the whole svn:mergeinfo without SVN itself falling apart.
However, some things won't work "right" automatically any more. In particular
SVN won't ignore requests to merge things that were already merged, because
it doesn't know about them. Now, the chance of someone merging from a deleted
branch (which is of course still possible!) are small, so I guess your method
is safe.


I guess it's safe. Some tests made today brought much fewer mergeinfo 
entries and merges with existing branches are still possible.
Naturally i'm losing some tracking information, but as you notice chance 
to need it are small. And in fact, if i really wanted to go back to 
state before cleaning action i could edit mergeinfo properties manually.


greetings
--
Piotr Kabacinski
a2Fib3Q=

externals behavior with tags

[amol gole]

I am a tortise svn user. I recently started trying the svn:externals property 
to 
share files between projects. I got this feature to work and I am happy with it 
so far. 


My question is related to how tags should behave with such shared files. I use 
tags as snapshots of my project in time. The tag is a copy of my trunk/branch 
when I created it. However, if I am using shared files via the externals 
property, these externally linked files will not be static - they will change 
if 
I do an update on my tag! This is definitely not the behavior I'm looking for. 


Immediately I can think of 2 ways to "fix" this behavior of the tag not being 
truly static:
1. In a tag, externally linked files loose their external link and are now just 
copies of the files. (yuck)
2. In a tag, the svn:externals property is changed slightly such that it points 
to the specific revision of the file when the tag was created. (using -rREV url 
filename format) 


Is this really a problem or is there another fix available that I am unaware 
of? 


Thanks,
AG


  

Re: externals behavior with tags

[NN Ott]

On Wed, Jan 26, 2011 at 5:02 PM, amol gole  wrote:

> I am a tortise svn user. I recently started trying the svn:externals
> property to share files between projects. I got this feature to work and I
> am happy with it so far.
>
> My question is related to how tags should behave with such shared files. I
> use tags as snapshots of my project in time. The tag is a copy of my
> trunk/branch when I created it. However, if I am using shared files via the
> externals property, these externally linked files will not be static - they
> will change if I do an update on my tag! This is definitely not the behavior
> I'm looking for.
>
> Immediately I can think of 2 ways to "fix" this behavior of the tag not
> being truly static:
> 1. In a tag, externally linked files loose their external link and are now
> just copies of the files. (yuck)
> 2. In a tag, the svn:externals property is changed slightly such that it
> points to the specific revision of the file when the tag was created. (using
> -rREV url filename format)
>
> Is this really a problem or is there another fix available that I am
> unaware of?
>
>

Option 2 is supported, and in fact is the recommended method.

See:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals

Re: externals behavior with tags

[Les Mikesell]

On 1/26/2011 4:36 PM, NN Ott wrote:


I am a tortise svn user. I recently started trying the svn:externals
property to share files between projects. I got this feature to work
and I am happy with it so far.

My question is related to how tags should behave with such shared
files. I use tags as snapshots of my project in time. The tag is a
copy of my trunk/branch when I created it. However, if I am using
shared files via the externals property, these externally linked
files will not be static - they will change if I do an update on my
tag! This is definitely not the behavior I'm looking for.

Immediately I can think of 2 ways to "fix" this behavior of the tag
not being truly static:
1. In a tag, externally linked files loose their external link and
are now just copies of the files. (yuck)
2. In a tag, the svn:externals property is changed slightly such
that it points to the specific revision of the file when the tag was
created. (using -rREV url filename format)

Is this really a problem or is there another fix available that I am
unaware of?



Option 2 is supported, and in fact is the recommended method.

See:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals


And if you want the externals references on your trunk to float with the 
trunk of the referenced item during development, one approach is to 
always make an intermediate branch where you make these and any other 
needed changes before making the tag.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Checkout really slow in Windows with lots of files in one directory

[Johan Corveleyn]

On Wed, Jan 26, 2011 at 7:32 PM, Daniel Shahaf  wrote:
> Johan Corveleyn wrote on Wed, Jan 26, 2011 at 17:15:40 +0100:
>> If I have more time, I'll try to search the archives some more.
>
> If it helps your code/mail grepping, I believe you're talking about
> svn_io_open_uniquely_named().

Thanks, Daniel! That was exactly the search term I needed. Here is the
thread (from the dev-list) that describes exactly the same problem:

http://svn.haxx.se/dev/archive-2010-04/0180.shtml

Neil, please read that thread, and you'll see that it describes
exactly the same problem. It contains some interesting discussions and
points. As far as I understand it, it has been fixed for 1.7, but not
backported to 1.6 (backport was suggested, but the discussion ended
somewhere "in the middle").

Maybe someone else can comment more on this, and why it wasn't
backported to 1.6 (or is it?).

HTH,
-- 
Johan

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Donner, Sean P]

> It's because of how CramMD5 works.
>
> "The server needs access to the users' plain text passwords."
> http://en.wikipedia.org/wiki/CRAM-MD5
>
> Stefan

Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
'use-sasl = true' to get this functionality.  So my original question stands as
to what SASL is buying us when it still requires plain-text passwords to be
stored on the server?

-Sean

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Stefan Sperling]

On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
> > It's because of how CramMD5 works.
> >
> > "The server needs access to the users' plain text passwords."
> > http://en.wikipedia.org/wiki/CRAM-MD5
> >
> > Stefan
> 
> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
> 'use-sasl = true' to get this functionality.

That's correct. But you can still configure SASL do to CRAM-MD5.
So there might be a bug in svn.
Maybe it still assumes that plaintext passwords will always be present.

> So my original question stands as
> to what SASL is buying us when it still requires plain-text passwords to be
> stored on the server?

Unfortunately the sasl stuff is not being maintained very actively.
The developers who wrote it aren't active anymore.
There are a couple of outstanding issues (some with half-done patches
floating around) that haven't been addressed due to lack of interest
and resources.

So if you want to help out with investigating this problem more closely
and possibly also help with fixing this the Subversion project would
be grateful.

Stefan

unsubscribe

[Brent Rhea]

unsubscribe

Re: directory problem on 'svn ci'

[Ryan Schmidt]

On Jan 26, 2011, at 12:21, Daniel Shahaf wrote:

> Ryan Schmidt wrote on Wed, Jan 26, 2011 at 09:12:44 -0600:
>> Note I did all tests with apr 1.4.2 and apr-util 1.3.10. Perhaps this
> 
> Just curious, why mix apr/apr-util of different minor (1.%d) versions?

These are the current versions available in MacPorts at this time.

Re: directory problem on 'svn ci'

[Ryan Schmidt]

On Jan 26, 2011, at 12:19, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Wed, Jan 26, 2011 at 09:12:44 -0600:
>> If I am in a subdirectory of that working copy and I commit,
>> svn-commit.tmp is created in the parent directory. For example, if
>> I am in /path/to/wc/foo/bar and I commit, svn-commit.tmp is created in
>> /path/to/wc/foo.
> 
> The directory of the tempfile depends on the invocation.  IIRC it's
> different for 'cd wc/sub/dir/; svn ci foo' and 'svn ci wc/sub/dir/' and
> 'svn ci wc/sub/dir/foo'.

In all my tests above, I used "cd" to get to the directory in question, then 
"svn ci" without specifying a path.

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Nico Kadel-Garcia]

On Wed, Jan 26, 2011 at 9:26 PM, Stefan Sperling  wrote:
> On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
>> > It's because of how CramMD5 works.
>> >
>> > "The server needs access to the users' plain text passwords."
>> > http://en.wikipedia.org/wiki/CRAM-MD5
>> >
>> > Stefan
>>
>> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
>> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
>> 'use-sasl = true' to get this functionality.
>
> That's correct. But you can still configure SASL do to CRAM-MD5.
> So there might be a bug in svn.
> Maybe it still assumes that plaintext passwords will always be present.
>
>> So my original question stands as
>> to what SASL is buying us when it still requires plain-text passwords to be
>> stored on the server?
>
> Unfortunately the sasl stuff is not being maintained very actively.
> The developers who wrote it aren't active anymore.
> There are a couple of outstanding issues (some with half-done patches
> floating around) that haven't been addressed due to lack of interest
> and resources.
>
> So if you want to help out with investigating this problem more closely
> and possibly also help with fixing this the Subversion project would
> be grateful.

Or switch to svn+ssh for SSH key based access, which has other advantages.