RE: Subversion queries hanging, timing out

[Ullrich.Jans]

Hi, 

(sorry for the format - OutBarf again..)


From: Dave Purrington [mailto:dave.purring...@gmail.com] 
Sent: Monday, January 11, 2010 8:25 PM
To: users@subversion.apache.org
Subject: Subversion queries hanging, timing out


Hello,

Lately we have been experiencing intermittent timeouts with our
Subversion operations. It does not happen initially, but after a while
it starts happening.Restarting Apache alleviates the problem, but it
comes back after a time. As you can imagine, this wreaks havoc.

[...]

depending on how many users you have, you might want to check the
max_clients setting in Apache - I was bitten by this recently. The
default is 150 (AFAIK) and that's too small. Increase it somewhat (like
500), reload Apache. This might help - in my case, it did. 

I think the reason behind that is clients keeping the connection to the
server alive and the server running out of slots.

Cheers,

Ulli




Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: NetDrive and SVN autoversioning - keep getting Broken pipe

[Gunther Mayer]

Richard Walker wrote:
2010/1/12 Gunther Mayer >


Hi guys,

I'm not sure if anyone here is working with the following
combination (or similar):

Server: svn 1.6.5 (latest) + apache 2.2.12 (latest) on ubuntu
karmic(9.10) 64bit
Client: Windows XP or Vista, NetDrive 1.0.8.11 (latest)

Server is configured to do autoversioning via WebDAV as per svnbook:


  DAV svn
  SVNParentPath /var/svn
  SVNAutoversioning on
  ModMimeUsePathInfo on


My client can mount(connect) this "drive" just fine and browse
through the directory hierarchy but when trying to open any files
they are corrupted because they're only half retrieved from the
server (tried it on a couple of large text files). Every now and
then NetDrive reports errors but nothing helpful. At the same time
the following appears in my apache error logs over and over again:

[Tue Jan 12 13:42:32 2010] [error] [client xx.xx.xx.xx] (32)Broken
pipe: Could not write data to filter.  [500, #0]
[Tue Jan 12 13:42:32 2010] [error] [client xx.xx.xx.xx] Unable to
deliver content.  [500, #0]

and occasionally

[Tue Jan 12 13:42:31 2010] [error] [client 196.7.14.173] Unable to
deliver content.  [500, #0]
[Tue Jan 12 13:42:31 2010] [error] [client 196.7.14.173]
(104)Connection reset by peer: Could not write data to filter.
 [500, #0]

This happens almost all the time and makes my repo kind of useless
on Windows (no, tortoisesvn won't work because we're dealing with
very non-technical users...). I know NetDrive is commercial
software but firstly it did come recommended in the svn book with
supposedly no known issues and secondly it is (apart from
WebDrive) my only option when it comes to mounting my svn
repository as a file system on Windows. It seems like some kind of
buffering problem but not sure how helpful the Novell support will
be in trouble shooting this one...

Any help or pointers would be greatly appreciated.

Gunther


Hi Gunther.

Good on you for trying! I used a similar combination for a while to 
version my My Documents folder in Windows. I also enthusiastically 
pushed this setup on a couple of non-technical people as a backup 
solution. The idea of it is fantastic - just working with files as 
normal but having all changes automatically versioned behind the 
scenes. Although I didn't see the problem you're describing, I did 
have issues and eventually gave it up.


Yes, the idea is fantastic and it's the reason I'm still persisting...


It ate disk space. Webdrive/netdrive used to buffer everything. It 
also really slowed my machine down. Putting the entire My Documents 
folder in there was also a mistake -  iTunes and other programs filled 
the repository with gigabytes of temporary file history. I also seem 
to remember the drives would drop out occasionally which led to me 
getting lynched!


Well, I've given up on Netdrive for now because I cannot get it to work, 
trying WebDrive now which comes with a 20day trial period and seems much 
more powerful. It has serious issues with self signed server 
certificates on Vista (XP doesn't complain) as I use SSL, haven't 
figured that one out yet but I could always get a commercial certificate 
if push comes to shove. I got my colleague onto using WebDrive now, it 
seems to work fine but only time will tell how stable it is (and whether 
we'll end up buying licenses).



I guess a big part of the problem is the lack of webDav file system 
support in Windows. I didn't feel that webdrive/netdrive really cut 
it. However, I did always wonder how it would behave if you mounted 
the repository as a webDAV directory in the file system of your linux 
server, and then shared that via samba to expose it to the windows 
machines rather than have them run netdrive? Perhaps it would be worth 
a try?


Ah, that's an interesting one which I haven't yet tried. However I think 
doing it this way will lose you the owner information - who made what 
changes. Doubt samba can pass through user credentials to davfs2.


Wishing you the best of luck! I'd like to know how you get on. Anybody 
else out there tried anything like this?


I'd also like to know if anyone out there is doing anything similar...


Gunther

use-commit-times = yes

[Claudius Sailer]

Hi,

we have our Client configured with the setup

use-commit-times = yes

is it possible with a svn or svn-admin command to modify this commit-times
in the repository?


bye


Claudius

Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart

Re: Question about excessive mergeinfo

[Javier Sanz]

That's an awesome hook to limit svn:mergeinfo propagation, but
unfortunately it is not viable for complex repositories :(.

Let's hope Subversion 1.7 helps us with this.

On Wed, Jan 13, 2010 at 11:46 AM, Stein Somers  wrote:
>> I have a pre-commit hook to detect mergeinfo
>> below root, and remove it whenever it occurs
>
> For clarity: the pre-commit hook detects and rejects. The one removing the
> mergeinfo is me, using svn propdel.
>
> Someone asked for the hook code, here it is. It's not my submission for a
> beauty contest and there are some unrelated checks in there. I use the SVN
> command line instead of python bindings because I can't find the slightest
> explanation on them.
>
> --8>
>
> #!/usr/bin/python
>
> # PRE-COMMIT HOOK
> SVNLOOK = '/usr/bin/svnlook'
>
> import subprocess
> import sys
>
> repos, txn = sys.argv[1:]
>
> rc = 0
>
> """
> logmsg = subprocess.Popen([SVNLOOK, 'log', repos, '--transaction', txn],
> stdout=subprocess.PIPE).stdout.read()
> if logmsg.isspace():
>        sys.stderr.write("Empty log message\n")
>        rc = 1
> """
>
> changes = subprocess.Popen([SVNLOOK, 'changed', repos, '--transaction',
> txn], stdout=subprocess.PIPE).stdout.readlines()
> for change in changes:
>        action = change[0]
>        assert(change[3] == ' ')
>        path = change[4:-1] # strip 2 leading change type characters followed
> by a space, and strip trailing newline
>        is_dir = path.endswith('/')
>        is_top_dir = False
>        if is_dir:
>                path_parts = path.split('/')
>                assert(path_parts[-1] == '')
>                if len(path_parts) == 2 and path_parts[0] == 'trunk':
>                        is_top_dir = True
>                if len(path_parts) == 3 and path_parts[0] in ('branches',
> 'tags'):
>                        is_top_dir = True
>
>        if action != 'D': # Delete
>                props = []
>                for entry in subprocess.Popen([SVNLOOK, 'proplist', repos,
> '--transaction', txn, path], stdout=subprocess.PIPE).stdout:
>                        assert(entry.startswith('  '))
>                        prop = entry[2:-1]
>                        props.append(prop)
>
>                if is_top_dir and not 'svn:mergeinfo' in props:
>                        sys.stderr.write(path + ": missing svn:mergeinfo\n")
>                        rc = 1
>                if not is_top_dir and 'svn:mergeinfo' in props:
>                        sys.stderr.write(path + ": unexpected
> svn:mergeinfo\n")
>                        rc = 1
>                if not is_top_dir and 'bugtraq:url' in props:
>                        sys.stderr.write(path + ": unexpected bugtraq:url\n")
>                        rc = 1
>                if not is_top_dir and 'bugtraq:logregex' in props:
>                        sys.stderr.write(path + ": unexpected
> bugtraq:logregex\n")
>                        rc = 1
>                if not is_dir and not 'svn:mimetype' in props: # then it's
> some kind of text file
>                        for line in subprocess.Popen([SVNLOOK, 'cat', repos,
> '--transaction', txn, path], stdout=subprocess.PIPE).stdout:
>                                if "DO_NOT_COMMIT" in line:
>                                        sys.stderr.write(path + ": found
> DO_NOT_COMMIT\n")
>                                        rc = 1
>                                        break
>
> sys.exit(rc)
>
> --8>
>
> --
> Stein
>



-- 
Un saludo,

Javier

Re: use-commit-times = yes

[Andy Levy]

On Thu, Jan 14, 2010 at 07:01, Claudius Sailer  wrote:
>
> Hi,
>
> we have our Client configured with the setup
>
> use-commit-times = yes
>
> is it possible with a svn or svn-admin command to modify this commit-times
> in the repository?

use-commit-times is only used by the client to set the timestamp of
checked-out/updated files.

To modify the commit time in the repository, you essentially have to
modify the history of your repository, changing the timestamp on
selected revisions (you aren't changing the times on the *files*, but
changing the record of when the *revision* was committed). At best,
this will be confusing when reading logs; at worst, it'll really mess
up your history, especially if you have other commits where you aren't
messing around with timestamps.

RE: Verifying a file version

[Headley, Ronald (PSC/ISMS/EAD-CTR)]

Thanks Ryan.  Parsing the output really isn't a big deal.  I guess I was
hoping for a more eloquent solution.

Any suggested reading for SVN?  Specifically, we're looking at
establishing baselines for our systems using SVN.  Can this be done
using this tool?

Ron Headley
Contractor 
HHS/PSC/ISMS/ESS PMO (Program Management Office)
(a SDVOSB)
301-525-3801 (cell)

-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
Sent: Wednesday, January 13, 2010 6:24 PM
To: Headley, Ronald (PSC/ISMS/EAD-CTR)
Cc: users@subversion.apache.org
Subject: Re: Verifying a file version


On Jan 13, 2010, at 16:02, Headley, Ronald (PSC/ISMS/EAD-CTR) wrote:

> We recently encountered an issue where an incorrect version, or more
specifically, a non-existing version, of a file was promoted to
production.  We want to enhance our process to ensure we, at a minimal,
export an existing version of a file.  Can anyone suggest a command that
will check the file version (without parsing the output of the list
command; I'd rather check the execution of the command with "echo $?" or
something to that effect)?  See examples below for further details.

To correct the terminology, you're trying to verify the "last changed
revision" of the file. And I don't think you're going to find a solution
that doesn't involve parsing the output of some svn command.

Re: Unable to change a commit message

[Johan Corveleyn]

Hi Kari,

[putting users@ back in cc, so other people can chime in if they can help]

On Tue, Jan 12, 2010 at 7:51 PM,   wrote:
> I didn't change the hook. I'm not totally sure how to change it. I initially
> commented out the line about exiting but after you suggested that was why it
> was failing, I switched that back. It's still hanging with the hooks back in
> their original state. As you can probably tell, I'm rather new at this and
> welcome any advise on correctly editing this to suit my needs.
>
> #!/bin/sh
>
[ ... snip default comments ... ]
>
>
> REPOS="$1"
> REV="$2"
> USER="$3"
> PROPNAME="$4"
> ACTION="$5"
>
> if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
>
> echo "Changing revision properties other than svn:log is prohibited" >&2
> exit 1
>
>
> Kari McNair

That hook looks fine to me.

Maybe you can still check for some issues:
- make sure the hook doesn't have line-termination issues (mixed
unix/windows/mac line termination, maybe not showing up in some
editors, but preventing it from being executed correctly).
- make sure the hook is executable by the user that needs to execute
it. Which user this is depends on your server setup (with Apache, the
hook must be executable by the user that runs Apache; with svnserve
and svn+ssh it depends on how you set it up).

BTW, you should probably give some more info about your svn server:
- What version is it?
- What operating system is it running on?
- How do you connect (http(s) or svnserver or svn+ssh)?

Regards,
Johan

>  Original Message 
> Subject: Re: Unable to change a commit message
> From: Johan Corveleyn 
> Date: Tue, January 12, 2010 7:53 am
> To: Kari McNair 
>
> On Mon, Jan 11, 2010 at 10:19 PM, Kari McNair 
> wrote:
>> I'm trying to remove an invalid character from the end of a commit
>> message.
>> All the correct hooks are invoked but when I use...
>> $ svn propset -r 671 --revprop svn:log "message" URL
>> ...the command prompt window just hangs. I tried changing the message
>> through TortoiseSVN but when I go to save the new message, it freezes.
>> I've
>> even just tried editing it from a Mac through Terminal and that just hangs
>> as well. Anyone have any other ideas?
>
> Only thing I can think of is that your pre-revprop-change hook causes
> the hang. Can you share the contents of that hook?
>
> Otherwise, as a first step, try to add some debug logging code to the
> pre-revprop-change hook (echo some stuff to a file at the beginning of
> your hook, and at the end). So you can see at least if the hook is
> entered and exited correctly ...
>
> Alternatively, if you don't care deeply about this issue, you can also
> change log messages on the server itself by using the svnadmin command
> (bypassing hooks if necessary):
> -
> $ svnadmin help setlog
> setlog: usage: svnadmin setlog REPOS_PATH -r REVISION FILE
>
> Set the log-message on revision REVISION to the contents of FILE. Use
> --bypass-hooks to avoid triggering the revision-property-related hooks
> (for example, if you do not want an email notification sent
> from your post-revprop-change hook, or because the modification of
> revision properties has not been enabled in the pre-revprop-change
> hook).
>
> NOTE: Revision properties are not versioned, so this command will
> overwrite the previous log message.
>
> Valid options:
> -r [--revision] ARG : specify revision number ARG (or X:Y range)
> --bypass-hooks : bypass the repository hook system
> -
>
> Regards,
> Johan
>

Inconsistent changes update

[Gathogo Richard]

Hi,
I am   Richard. I have a problem that
sometimes when I make changes to my files locally, I can not see
those changes after running the project locally. But is I commit
others will see them. What could be wrong and what can I do to
correct that. Feel free to ask more details.

Regards
Richard Gathogo.


  

Windows 7 entries file locking

[David Turner]

>From the TortoiseSVN lists:

A few people have raised this: a check-out on Windows 7 often fails
because entries is unreadable. This is caused by antivirus software and/or
Windows indexing services competing for file locks. It's fairly easy to
reproduce with a large repository on Windows 7 if you have antivirus
software and are checking out into an indexed folder.

Obviously those of us in a corporate environment don't have the option
of disabling our antivirus software.

Is it possible to keep entries open with exclusive access for the
duration of the move from tmp/entries to entries?

Problem with merge tracking information in conjunction with file externals

[Andreas Ländle]

Hello,

 

I discovered an imperfection of subversion 1.6.6 (at least in my eyes) last 
days when I was merging some files from our trunk into the stable branch.

All the merge tracking information of all files in one directory have been 
changed.

The detailed situation was the following.

/ (added svn:mergeinfo /trunk:r4)

/directory1   (added svn:mergeinfo /trunk/directory1:r4*)

/directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)

 

Take into account that file1 represents a few dozen files in the 
'directory1'-directory (all with the same 'r4'-mergeinfo).

In my eyes the merge information for /directory1 and the files in it is 
redundant.

Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information down 
to the "root"?

 

Is this behavior correct? Or have I found a bug or at least an imperfection in 
subversion?

I have attached a batch script (see below) that reproduces the issue - or at 
least it should illustrate what I was doing.

 

How can I avoid the creation of this bunch of merge tracking information during 
the merge?

Surely, I can revert the merge-information on directory1 before committing my 
merges (but that seems to be very inconvenient).

 

Thanks in advance for any hint.

 

Best regards,

 

Andreas Ländle

 

 

rem create test environment

rmdir TestSvnMerge /S /Q

mkdir TestSvnMerge

cd TestSvnMerge

svnadmin create repos

mkdir project

mkdir project\trunk

mkdir project\trunk\a

mkdir project\trunk\b

echo "EXTERNAL" > project\trunk\b\content.txt

echo "FILE" > project\trunk\a\file1.txt

echo "FILE" > project\trunk\a\file2.txt

svn import project file:///testsvnmerge/repos -m "Import"

rmdir project /S /Q

 

rem co trunk & create external

svn co file:///testsvnmerge/repos/trunk trunk-wc

svn propset svn:externals "../b/content.txt content.txt" trunk-wc\a

svn ci trunk-wc -m "Added external"

svn update trunk-wc

 

rem create branch

svn copy file:///testsvnmerge/repos/trunk file:///testsvnmerge/repos/branch -m 
"Created branch"

svn co file:///testsvnmerge/repos/branch branch-wc

 

rem edit file (in trunk)

echo "FILE1" > trunk-wc\a\file1.txt

svn ci trunk-wc -m "Edited file"

 

rem merge from trunk in branch

svn merge -r 3:4 trunk-wc branch-wc

 

rem visualize the problem

svn diff branch-wc

svn status branch-wc

cd..

 

**
Soloplan GmbH
Software für Logistik und Planung
Andreas Ländle
Entwicklung
Burgstraße 20 | 87435 Kempten | Deutschland
Telefon: +49 831 57407-465 | Telefax: +49 831 57407-111
E-Mail: a...@soloplan.de   | Web: www.soloplan.de 
 
Geschäftsführer: Wolfgang Heidl, HRB 5304 Kempten

 

RE: Problem with merge tracking information in conjunction with file externals

[Bob Archer]

> I discovered an imperfection of subversion 1.6.6 (at least in my eyes)
> last days when I was merging some files from our trunk into the stable
> branch.
> All the merge tracking information of all files in one directory have been
> changed.
> The detailed situation was the following.
> /     (added svn:mergeinfo /trunk:r4)
> /directory1   (added svn:mergeinfo /trunk/directory1:r4*)
> /directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
> 
> Take into account that file1 represents a few dozen files in the
> 'directory1'-directory (all with the same 'r4'-mergeinfo).
> In my eyes the merge information for /directory1 and the files in it is
> redundant.
> Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information
> down to the "root"?

This really depends on what other merge info is there. I assume those are not 
the only mergeinfo paths on those folders/files.

> 
> Is this behavior correct? Or have I found a bug or at least an
> imperfection in subversion?

It is possible. I have heard people say that superfluous merge info is created 
when using externals. Have you tried your script without it containing 
externals?

> I have attached a batch script (see below) that reproduces the issue - or
> at least it should illustrate what I was doing.
> 
> How can I avoid the creation of this bunch of merge tracking information
> during the merge?
> Surely, I can revert the merge-information on directory1 before committing
> my merges (but that seems to be very inconvenient).

Yes, that should be ok, assuming there is no other mergeinfo on that 
folder/files.

BOb

Re: sync bug -> corrupted proxy repo

[Johan Corveleyn]

On Wed, Jan 13, 2010 at 2:27 PM, Giulio Troccoli
 wrote:
>> From: Jon Foster [mailto:jon.fos...@cabot.co.uk]
>> Sent: 13 January 2010 13:13
>> To: Andersen, Krista; users@subversion.apache.org
>> Cc: ssi-svn_admin
>> Subject: RE: sync bug -> corrupted proxy repo
>>
>> Hi,
>>
>> Andersen, Krista [mailto:krista.ander...@itg.com] wrote:
>> > Twice I have seen one of my proxy repositories become
>> corrupted due to
>> > an apparent bug in the svnsync sync process.  Has anyone else seen
>> > this type of behavior from Subversion?
>>
>> This is probably caused by issue 3546 [1][2].  This is a race
>> condition - if you have several sync processes running at the
>> same time then the mirror can get corrupted.  You had three
>> commits which were 1 second apart, so your hook script
>> started 3 copies of svnsync within 2 seconds.  I think this
>> is the first practical report of this bug; previous
>> discussion was theoretical.
>>
>> > Here is a comparison the output of the svn log -v for the offending
>> > revisions (324,325) on both the corrupted and non-corrupted proxy
>> > repo.
>>
>> It looks like rev 323 got mirrored twice (as mirror revs 323
>> and 324), then rev 324 was mirrored (as mirror rev 325).
>>
>> > I am a bit concerned about the stability of Subversion
>> since this is
>> > the second time in two months that I have had to fix this issue.
>> > Is there a patch or something to prevent this in the future?
>>
>> Suggested workaround: Change your hook scripts to use the
>> lockf or lockfile tools[3] to ensure that only one instance
>> of svnsync runs at once.
>
> Is it not the case that a svn commit cannot start before the post-commit 
> hooks has finished? I am asking becuase I will be implementing a DR system 
> using svnsync, but I am not planning to let the post-commit finish before 
> svnsync has finished (I don't care if it takes a bit longer, I can cope with 
> that and with my users).

No, that's definitely not the case. Both pre-commit and post-commit
hooks can run simultaneously for multiple commits in parallel.
Otherwise, a pre/post-commit hook could end up being a big bottleneck.

As a practical example: if your pre-commit hook does validation of
properties (e.g. making sure svn:eol-style is set correctly on the
right types of files), then for a commit with a lot of files it may be
running for multiple seconds (even minutes). In the meantime, other
commits can be made without problems, without being bothered by that
one commit which takes a long time to pass through pre-commit hook. I
saw this in action myself with such a pre-commit hook, after I added
some debug logging at the start and the end of the hook.

Regards,
Johan

Re: Subversion queries hanging, timing out

[Dave Purrington]

Great feedback from both of you, thanks for the help. In the meantime, we've
decided to stop using mod_auth_sspi. Hopefully, that will mitigate some of
this. But we definitely have more than 150 users, so I'll take a look at the
max_clients setting.

Cheers!

-dave

On Thu, Jan 14, 2010 at 4:37 AM,  wrote:

> Hi,
>
> (sorry for the format - OutBarf again..)
> 
>
>From: Dave Purrington [mailto:dave.purring...@gmail.com]
>Sent: Monday, January 11, 2010 8:25 PM
>To: users@subversion.apache.org
>Subject: Subversion queries hanging, timing out
>
>
>Hello,
>
>Lately we have been experiencing intermittent timeouts with our
> Subversion operations. It does not happen initially, but after a while
> it starts happening.Restarting Apache alleviates the problem, but it
> comes back after a time. As you can imagine, this wreaks havoc.
>
> [...]
>
> depending on how many users you have, you might want to check the
> max_clients setting in Apache - I was bitten by this recently. The
> default is 150 (AFAIK) and that's too small. Increase it somewhat (like
> 500), reload Apache. This might help - in my case, it did.
>
> I think the reason behind that is clients keeping the connection to the
> server alive and the server running out of slots.
>
> Cheers,
>
> Ulli
>
>
>
> 
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>
>

Re: Windows 7 entries file locking

[Dave Purrington]

FWIW, I'm on Windows 2008 Server R2 (the server version of Windows 7) with a
large repo. I have Windows Search enabled as well as virus scanning. The
only time I have seen this behavior is running Filemon or Procmon during svn
operations.

On Thu, Jan 14, 2010 at 4:59 AM, David Turner  wrote:

> From the TortoiseSVN lists:
>
> A few people have raised this: a check-out on Windows 7 often fails
> because entries is unreadable. This is caused by antivirus software and/or
> Windows indexing services competing for file locks. It's fairly easy to
> reproduce with a large repository on Windows 7 if you have antivirus
> software and are checking out into an indexed folder.
>
> Obviously those of us in a corporate environment don't have the option
> of disabling our antivirus software.
>
> Is it possible to keep entries open with exclusive access for the
> duration of the move from tmp/entries to entries?
>

AW: Problem with merge tracking information in conjunction with file externals

[Andreas Ländle]

Hello Bob,

thanks for the quick answer. It's safe to assume that the published mergeinfo 
paths are the only merge information on those folders/files.
And of course - if I didn't include the external then the problem doesn't 
emerge.

Andreas

-Ursprüngliche Nachricht-
Von: Bob Archer [mailto:bob.arc...@amsi.com] 
Gesendet: Donnerstag, 14. Januar 2010 16:00
An: Andreas Ländle; users@subversion.apache.org
Betreff: RE: Problem with merge tracking information in conjunction with file 
externals

> I discovered an imperfection of subversion 1.6.6 (at least in my eyes)
> last days when I was merging some files from our trunk into the stable
> branch.
> All the merge tracking information of all files in one directory have been
> changed.
> The detailed situation was the following.
> /     (added svn:mergeinfo /trunk:r4)
> /directory1   (added svn:mergeinfo /trunk/directory1:r4*)
> /directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
> 
> Take into account that file1 represents a few dozen files in the
> 'directory1'-directory (all with the same 'r4'-mergeinfo).
> In my eyes the merge information for /directory1 and the files in it is
> redundant.
> Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information
> down to the "root"?

This really depends on what other merge info is there. I assume those are not 
the only mergeinfo paths on those folders/files.

> 
> Is this behavior correct? Or have I found a bug or at least an
> imperfection in subversion?

It is possible. I have heard people say that superfluous merge info is created 
when using externals. Have you tried your script without it containing 
externals?

> I have attached a batch script (see below) that reproduces the issue - or
> at least it should illustrate what I was doing.
> 
> How can I avoid the creation of this bunch of merge tracking information
> during the merge?
> Surely, I can revert the merge-information on directory1 before committing
> my merges (but that seems to be very inconvenient).

Yes, that should be ok, assuming there is no other mergeinfo on that 
folder/files.

BOb

RE: Verifying a file version

[Headley, Ronald (PSC/ISMS/EAD-CTR)]

Thanks Andy.  We really want to work with a file version, or revision, as 
opposed to a tree revision.   Suppose there are three revisions of File-1 in 
the repository and one revision of File-2.

File-1 revision 63
File-1 revision 64
File-2 revision 65
File-1 revision 66

Suppose we want to deploy File-1 revision 66 but the developer specifies 
revision 65 (which doesn't exist) when creating the deployment package (HP 
Kintana).  In this scenario, File-1 revision 64 will be exported and deployed.  
This is what happened and is what we want to avoid.  Do you have any 
suggestions?

Perhaps the wrong tool was selected or perhaps it is not setup correctly or 
we're not using it correctly.  Either way, it is what we have to work with and 
we're trying to improve our processes.  We're also looking at establishing 
baselines for our systems using SVN.  Can this be done?

Any suggestions would be greatly appreciated.

Ron Headley
Contractor 
HHS/PSC/ISMS/ESS PMO (Program Management Office)
(a SDVOSB)
301-525-3801 (cell)

-Original Message-
From: Andy Levy [mailto:andy.l...@gmail.com] 
Sent: Wednesday, January 13, 2010 6:24 PM
To: Headley, Ronald (PSC/ISMS/EAD-CTR)
Cc: users@subversion.apache.org
Subject: Re: Verifying a file version

On Wed, Jan 13, 2010 at 17:02, Headley, Ronald (PSC/ISMS/EAD-CTR)
 wrote:
> Good evening.
>
>
>
> We recently encountered an issue where an incorrect version, or more
> specifically, a non-existing version, of a file was promoted to production.
> We want to enhance our process to ensure we, at a minimal, export an
> existing version of a file.  Can anyone suggest a command that will check
> the file version (without parsing the output of the list command; I'd rather
> check the execution of the command with "echo $?" or something to that
> effect)?  See examples below for further details.
>

Use svn info.  svn list really seems like the wrong tool for the job
here. You'll still have to parse the output of svn info to read the
Last Changed Revision line.

>
> In this example, we execute a list on a file for a specific version.  As you
> can see, the list succeeded.
>
>
>
> $ svn list -r42 -v
> svn://...:000/Repository/
>
>  42    540672 Feb 17  2009 
>
> $ echo $?
>
> 0
>
>
>
> In this example, we execute a list on a file for a specific version.  As you
> can see, the list succeeded.  However, we hoped it would fail since the only
> version of the file is 42.

Why would you expect it to fail? You asked for svn ls as of revision
42, and the file existed at that revision.

>
> $ svn list -r61 -v
> svn://...:000/Repository/
>
>  42    540672 Feb 17  2009 
>
> $ echo $?
>
> 0


If the file hasn't been changed since r42, this still seems correct.

Re: Verifying a file version

[Andy Levy]

On Thu, Jan 14, 2010 at 11:30, Headley, Ronald (PSC/ISMS/EAD-CTR)
 wrote:
> Thanks Andy.  We really want to work with a file version, or revision, as 
> opposed to a tree revision.   Suppose there are three revisions of File-1 in 
> the repository and one revision of File-2.
>
> File-1 revision 63
> File-1 revision 64
> File-2 revision 65
> File-1 revision 66
>
> Suppose we want to deploy File-1 revision 66 but the developer specifies 
> revision 65 (which doesn't exist) when creating the deployment package (HP 
> Kintana).  In this scenario, File-1 revision 64 will be exported and 
> deployed.  This is what happened and is what we want to avoid.  Do you have 
> any suggestions?
>
> Perhaps the wrong tool was selected or perhaps it is not setup correctly or 
> we're not using it correctly.  Either way, it is what we have to work with 
> and we're trying to improve our processes.  We're also looking at 
> establishing baselines for our systems using SVN.  Can this be done?

Subversion doesn't have "file revisions." Revision 65 *does* exist,
and File-1 *does* exist in that revision - it just wasn't changed
then, so it looks identical to File-1 in revision 64.

Each revision number represents the state of the entire repository at
that moment in time. If File-1 wasn't changed in revision 65, File-1 @
r65 will look identical to File-1 @ r64.

>From your description (but I'm having a hard time understanding what
you're trying to achieve), Subversion may not be the right tool for
your requirements, or may require some significant layering of other
programs/scripts on top of it to get it to do what you want.

A "complex tag" may get you closer to where you want to be. See
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html#svn.branchmerge.tags.mkcomplex

Not sure what you're trying to do with "baselines" - is this for
detecting changes to items in (for example) a production environment?
That would be a better task for something like Tripwire.

RE: Verifying a file version

[Bob Archer]

> Thanks Andy.  We really want to work with a file version, or revision, as
> opposed to a tree revision.   Suppose there are three revisions of File-1
> in the repository and one revision of File-2.
> 
> File-1 revision 63
> File-1 revision 64
> File-2 revision 65
> File-1 revision 66
> 
> Suppose we want to deploy File-1 revision 66 but the developer specifies
> revision 65 (which doesn't exist) when creating the deployment package (HP

Sure it exists... the file in rev65 is the same one as in rev64. I'm not sure 
why you wouldn't deploy using all the files in a specific rev? 

One thing we do, which may be what you are looking for is put dependencies in 
the repository. So, in our lib folder we have version X of log4net.dll. This is 
allways used to build the deployment. If the devs decide to start using version 
x.1 they would update the binary in the lib folder.

> Kintana).  In this scenario, File-1 revision 64 will be exported and
> deployed.  This is what happened and is what we want to avoid.  Do you
> have any suggestions?

Subversion doesn't really work this way. You can basically ask for the file as 
it was in rev x. It may be the same in many revs of course. 

> Can anyone suggest a command that will check the file version

You can use a tool like SubWCRev Program from the Tortoise project which will 
tag the header with the latest version that a file was modified in.

BOb

svn load command does not restore all files from dump

[Jeremy Conlin]

I am trying to move my repository from one server to another.  I am
doing this by dumping the repository and moving the dump file and then
creating and loading a new repository on the new server.

The trouble is on the new server, not all of the files are restored.
The "svnadmin load Repo < dumpfile" command finishes (i.e. still shows
up when I do 'ps -aux') yet the size of the repository folder is not
increasing in size; no new data/files are being added.

Can someone provide some assistance with this situation?

Thanks,
Jeremy

Keyword expansion on Unicode text files

[Harald-René Flasch]

Hi,

what should I do in order to make keyword expansion on Unicode text files 
working (e.g. .inf files)?

- BOM is FF FE (used Notepad Save As --> Unicode to create the file)
- There is only the svn:keywords property on the file

Regards,
hfrmobile
  
_
Das neue Windows 7: Finden Sie den richtigen PC. Erfahren Sie mehr darüber.
http://windows.microsoft.com/shop

Re: Keyword expansion on Unicode text files

[Ryan Schmidt]

On Jan 14, 2010, at 13:15, Harald-René Flasch wrote:

> what should I do in order to make keyword expansion on Unicode text files 
> working (e.g. .inf files)?
> 
> - BOM is FF FE (used Notepad Save As --> Unicode to create the file)
> - There is only the svn:keywords property on the file

Sorry, AFAIK there still isn't a way to make svn:keywords work in UTF-16 files. 
See:

http://svn.haxx.se/users/archive-2005-11/0538.shtml

Possibly related tickets:

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

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

Re: sync bug -> corrupted proxy repo

[Ryan Schmidt]

On Jan 14, 2010, at 09:06, Johan Corveleyn wrote:

>> Is it not the case that a svn commit cannot start before the post-commit 
>> hooks has finished? I am asking becuase I will be implementing a DR system 
>> using svnsync, but I am not planning to let the post-commit finish before 
>> svnsync has finished (I don't care if it takes a bit longer, I can cope with 
>> that and with my users).
> 
> No, that's definitely not the case. Both pre-commit and post-commit
> hooks can run simultaneously for multiple commits in parallel.
> Otherwise, a pre/post-commit hook could end up being a big bottleneck.
> 
> As a practical example: if your pre-commit hook does validation of
> properties (e.g. making sure svn:eol-style is set correctly on the
> right types of files), then for a commit with a lot of files it may be
> running for multiple seconds (even minutes). In the meantime, other
> commits can be made without problems, without being bothered by that
> one commit which takes a long time to pass through pre-commit hook. I
> saw this in action myself with such a pre-commit hook, after I added
> some debug logging at the start and the end of the hook.

pre-commit hook, I believe you're right. But Subversion blocks the commit until 
the post-commit is done. Only one post-commit hook will run at a time. Unless 
you tell it to allow simultaneous runs, by redirecting the hook's stdout and 
stderr someplace.

Re: Unable to change a commit message

[Ryan Schmidt]

On Jan 14, 2010, at 08:43, Johan Corveleyn wrote:

> Hi Kari,
> 
> [putting users@ back in cc, so other people can chime in if they can help]
> 
> On Tue, Jan 12, 2010 at 7:51 PM,   wrote:
>> I didn't change the hook. I'm not totally sure how to change it. I initially
>> commented out the line about exiting but after you suggested that was why it
>> was failing, I switched that back. It's still hanging with the hooks back in
>> their original state. As you can probably tell, I'm rather new at this and
>> welcome any advise on correctly editing this to suit my needs.

You would need to change the hook in at least two ways before it will run:

1) Rename it: remove the ".tmpl" extension
2) Add the execute bit: "chmod a+x" it

You'll certainly need to do at least those steps if you haven't already.

Re: use-commit-times = yes

[David Weintraub]

The commit time is a property on the revision, svn:date. It is
possible for a user to edit this without leaving a trail. That's why
you cannot edit a revision property without a pre-revprop-change hook.
It is up to the administrator of the repository to create and maintain
this hook and to ensure that the standard user isn't modifying the
commit dates, the commit user, or the commit comments without
authorization.
-- 
David Weintraub
qazw...@gmail.com

Sasl and svnserve does not work

[postfix]

Hello list,

 i have a problem with svnserve + sasl auth. Version is 1.5.1 running on
Debian Lenny 64bit.

I Created a repo named "gdiproject" and a svnserve.conf and a
/var/lib/sasl2/svn.conf.

--svnserve.conf
# [general]
# anon-access = none
# auth-access = write
# password-db = passwd
# authz-db = authz
# realm = gdiproject
#
# [sasl]
# use-sasl = true
# min-encryption = 128
# max-encryption = 256
---

and

--/usr/lib/sasl2/svn.conf--
# pwcheck_method: auxprop
# auxprop_plugin: sasldb
# sasldb_path: /var/svn-repos/logins/svn_gdi_sasldb
# mech_list: ANONYMOUS DIGEST-MD5
---

When trying to execute a simple command like "info" i cannot login, and
/var/log/auth.log gives me this error:

"server svnserve: unable to open Berkeley db /etc/sasldb2: No such file or
directory".

In svn.conf i specified another file - why is sasl trying to load this
file and not the one specified?

The sasldb file was created like this: "saslpasswd2 -c -f svn_gdi_sasldb
-u gdiproject username" and has the rights 0660, owner
subversion:subverion (The user and group of SVN)

I hope you can help me to find out the reason for this strange behaviour.
Without using sasl and the plaintext passwd of svnserve everything works
fine...

Thanks in advance

Daniel Herrmann