Re: Anyone have solid SCM experience?

[Nico Kadel-Garcia]

On Thu, May 23, 2013 at 11:46 AM, Daniel Shahaf  wrote:
> Samantha Tilney wrote on Thu, May 23, 2013 at 11:12:09 -0400:
>> I figured you Subversion fiends might have some experience with Git ;)
>
> So?  This is a mailing list for Subversion user support.  It has 800+
> readers, most of whom are not looking for a 3-6 months contract for work
> on Git.  That suggests your post was off-topic.

This may be partly my fault. I'm getting a lot of calls for SCM work,
and have suggested that they *look* on the maiiling lists. I didn't
tell any of them to advertise on the *wrong* mailing lists, and
discouraed them from direct adversiting.

Re: Check SVN user permissions before commit

[Nico Kadel-Garcia]

On Fri, May 24, 2013 at 6:40 PM, Dennis Estenson
 wrote:
> Hello,
>
>
>
> I am not a subscriber to the list, so I would appreciate being CC'd on any
> replies.
>
>
>
> How would I go about checking for user (write) permissions without actually
> doing a procedure that might fail due to permissions?  Say, for example, I
> don't have write permissions to a project in SVN. I want to check that I
> have write permissions without trying to do a commit. In particular, I want
> to tag (svn cp) a number of projects, but I want to check that I have
> permission to perform the tags on every project before tagging any project.
> How would I do this?

It depends greatly on the access control methods. pre-commit scripts,
svnserve.conf for svn:// repositories,
/etc/httpd/conf.d/subversion.conf for the HTTPS based RPM's,,
filesystem access based control, and all sorts of complex local setups
prevent being able to do  a simple "pre-test this" operation.

Check SVN user permissions before commit

[Dennis Estenson]

Hello,

I am not a subscriber to the list, so I would appreciate being CC'd on any 
replies.

How would I go about checking for user (write) permissions without actually 
doing a procedure that might fail due to permissions?  Say, for example, I 
don't have write permissions to a project in SVN. I want to check that I have 
write permissions without trying to do a commit. In particular, I want to tag 
(svn cp) a number of projects, but I want to check that I have permission to 
perform the tags on every project before tagging any project. How would I do 
this?

Thanks,
Dennis Estenson

**
CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the 
individual or entity to whom it is addressed and may contain information that 
is privileged, confidential, and exempt from disclosure under applicable law. 
If you have received this communication in error, please do not distribute, and 
delete the original message. Please notify the sender by E-Mail at the address 
shown. Thank you for your compliance.

RE: Build on Pre-Commit

[Bob Archer]

> Hello,
> I know this has been asked already, but we would really like to reject any
> attempt to commit files which would break a project in trunk. The decision to
> reject the committed files is based on the result of the building process of 
> the
> project the files being committed belong to. I know that during the pre-commit
> phase the repository cannot be accessed concurrently, but this is not a 
> problem
> for us since our buildings are really fast and we can tolerate any delay 
> involved.
> Are there any tools to achieve what we want? Note that it will be necessary ro
> recompile the whole project unit, not just the single files being committed.
> Thanks.

I don't think there is ever a 100% certainty that a commit won't break a build 
even if that commit was ok on another branch. 

What is the problem you are trying to solve by doing this? One major point of 
continuous integration is that your builds break early, giving instant feedback 
so the dev can fix this issue. 

You can "move" the problem to a branch. All commits go to a branch and after 
the branch builds your build server merges that branch to trunk (or whatever) 
but that may still break the trunk build. 

This is best dealt with procedures. Do your devs have the same build.bat file 
(or whatever) that the build server does? They should... this way they can...

1. Make code changes test locally.
2. Update their working copy, run same build/test local that the build server 
runs.
3. If step two is successful commit to the server. 

BOb

Re: svn AD authentication

[Pavel Lyalyakin]

Hello Thomas,

> most users use tortoisesvn. What are the drawbacks of NTLM, SSPI, for 
> Tortoisesvn users? I read some articles about 401 errors etc...

What articles do you refer to? Generally speaking, using
NTLM/Negotiate over SSPI is harmless and does not lead to issues with
TortoiseSVN.

> Also, I do not have the AD under control and it would not be easy for me to 
> ask for changes in the AD. Btw. we are using the free version of Visualsvn 
> and I hope to be able to test 1.8rc2 soon.

VisualSVN Server's Integrated Windows Authentication does not require
you to customize or adjust Active Directory settings. Some AD
user/group management can be required to setup authorization rules though.

BTW we've just released VisualSVN Server 2.6.0-RC1, release candidate
built against Subversion 1.8-RC2. It's a good occasion to test SVN 1.8
as well as new features of VisualSVN Server 2.6. We hope you'll like
it! :)

You can download and check the VisualSVN Server 2.6-RC1 changes at
http://www.visualsvn.com/server/download/pre-release/

Thank you!

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: Commit fails on locked files

[HOUDROGE Rami]

Indeed, but I was still hoping someone from the dev community could confirm it 
is a compatibility issue, and possibly provide the reasons behind the errors.

In any case, thank you for taking the time to answer my questions.

Sincerely,

Rami

Le 24/05/2013 15:14, Johan Corveleyn a écrit :

On Fri, May 24, 2013 at 2:05 PM, HOUDROGE Rami
 wrote:
> I could provide a script, but I doubt it would be of any use. It will
> execute as it should on your pcs.
>
> I didn't clearly mention that subversion is installed on a Apache 2.2.17
> server with webdav_svn. We think there might be an incompatibility somewhere
> (see
> http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html)
>

Seems that thread already explains what the problem is, and how you can fix it.

"Yes it was solved for me.  All I did is build your apache with -enable-
pie option.  Without this some special characters will go with lock
files, and during commit your locks will not match. "

--
Johan

Re: Commit fails on locked files

[Johan Corveleyn]

On Fri, May 24, 2013 at 2:05 PM, HOUDROGE Rami
 wrote:
> I could provide a script, but I doubt it would be of any use. It will
> execute as it should on your pcs.
>
> I didn't clearly mention that subversion is installed on a Apache 2.2.17
> server with webdav_svn. We think there might be an incompatibility somewhere
> (see
> http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html)
>

Seems that thread already explains what the problem is, and how you can fix it.

"Yes it was solved for me.  All I did is build your apache with -enable-
pie option.  Without this some special characters will go with lock
files, and during commit your locks will not match. "

--
Johan

Bug report for Subversion 1.7.9

[Alexander Lüders]

Dear Subversion support team,

I want to file a bug report affecting Subversion 1.7.9.

In our software system, we currently use Subversion 1.6 and recognized a 
possible performance reduction (~ 15x times) in 1.7 concerning the deletion of 
files using JavaHL.

Let's start describing test environment + scenario:

Environment:

* Intel i7 2.6Ghz cpu

* 8Gb RAM

* Windows 7 x64 Professional

* Oracle JDK 1.6u37

* Subversion 1.6.21 x32 vs. 1.7.9 x32 (both downloaded from Collabnet)

Scenario:

I started setting up a local empty repository with full anonymous access.

svnadmin create repo --fs-type fsfs

Then I started two consecutive test runs, one time using 1.6.21, the other 
1.7.9. Each run involved three steps:

1) starting local server: svnserve.exe -d --listen-host localhost --listen-port 
 -r testrepo

2) checking out local working copy

3) running Java test program, which uses JavaHL to access the repository via 
SVN URL

The Java test program basically consists of 5 steps.

1) Copying N testfiles to the root of the working copy (N sequential copy 
operations).

2) Adding these N testfiles (N sequential add operations)

3) Committing these N testfiles (N sequential commit operations)

4) Deleting these N testfiles (N sequential delete operations)

5) Committing the deletion of the N testfiles (N sequential commit operations)

Each test was run with N = 50, i.e. I had 50 sequential copy, followed by 50 
add, commit, delete and again commit operations.

The two Java test programs had only minor modifications to account for the 
minor changes in the JavaHL Bindings in 1.6 and 1.7., respectively.

The calls to 'svn add', 'svn commit' and 'svn delete' were using the same 
parameters, which will subsequently be listed for completeness:

add:

path = absolute filePath

depth = Depth.empty

force = false

noIgnores = false

makeParents = false

commit:

paths = array/set with single path

depth = Depth.empty

noUnlock = false

keepChangeLists = false

changeLists = null

revPropTable = null

delete:

path = array/set with single path pointing to the file to be deleted (1.6) / 
deleted file (1.7)

force = true

keepLocal = false

revProp = null

commitCallback = null

The measurement was performed internally for each step using 
System.nanoseconds(). It represents the accumulated time for the specified step 
for the N runs.

These were the results:

Collabnet svn, version 1.6.21 (r1462351), N=50:

+ Results ++

  create:  55,678,140 nanoseconds

  add:323,881,044 nanoseconds

  commitadd:2,986,280,688 nanoseconds

  delete: 452,160,586 nanoseconds

  commitdelete: 3,262,215,833 nanoseconds



svn, version 1.7.9 (r1462340)

+ Results ++

  create:   58,092,656 nanoseconds

  add: 332,664,285 nanoseconds

  commitadd: 3,208,830,490 nanoseconds

  delete:  336,923,540 nanoseconds

  commitdelete: 49,467,846,354 nanoseconds



I can only speculate about the huge performance difference concerning the 
commit of the deleted file. There might be a connection with 1.7. removing the 
file immediately after a call to 'svn delete'.

Maybe a subsequent commit specifying a path to a file, which does not exist any 
more, results in additional lookup time during the commit operation.

At the moment this issue is preventing us from migrating to Subversion 1.7. Do 
you know if this issue can be fixed timely (or is already fixed in 1.8)?

P.S.: If interested I'm happy to deliver the Java sources.

Thanks in advance

Alexander Lüders

Re: Build on Pre-Commit

[Les Mikesell]

On Fri, May 24, 2013 at 5:05 AM, San Martino  wrote:
> We already use branches, but we use/justify them for developping long
> features or bug-fixes which require some time and are not urgent.
> In many cases, however, we must urgently fix small, short and important bugs
> and release everything immediatly.. We act on trunk directly for this and
> for this reason we shoule be sure that trunk is always ok. Opening a branch
> for each fix instead of using a validation on pre-commit makes the whole
> procedure more heavy does not guarantee that trunk is always in a "correct"
> state in any case. While searching on internet I found two "Pre-Commit CI" :
>
> http://www.pmease.com/features/continuous-integration.html#proof-build
> http://www.jetbrains.com/teamcity/features/delayed_commit.html
>
> I have not read the documentation, but it appears they are near to what we
> want
> What do you think about them?

Have you considered using release branches and accepting the
possibility of a 'dirty' trunk?  Projects that have to support
multiple release versions concurrently are pretty much forced to do it
that way, but it is not particularly cumbersome even if you only have
one revision deployed at a time now.   And the trunk seems like the
right place to have untested development work happening.

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

Re: SVN Error

[Branko Čibej]

On 24.05.2013 12:34, Thorsten Schöning wrote:
> Guten Tag Ajay Pawar,
> am Freitag, 24. Mai 2013 um 12:16 schrieben Sie:
>
>> I am able to access the repository through internet explorer but not through 
>> tortoise svn client.
> Then check the proxy settings of both, they may be different, with
> different auth credentials or something like that.

More likely it's the same proxy but it's broken. A browser will only
issue GET requests when browsing a Subversion repository, but a
Subversion client needs a lot more than that.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: Commit fails on locked files

[HOUDROGE Rami]

I could provide a script, but I doubt it would be of any use. It will execute 
as it should on your pcs.

I didn't clearly mention that subversion is installed on a Apache 2.2.17 server 
with webdav_svn. We think there might be an incompatibility somewhere (see 
http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html)

There's literally nothing more than what I indicated already :

1. new file
2. add file
3. commit file
4. lock file
5. modify file
6. commit file

Le 23/05/2013 16:17, Johan Corveleyn a écrit :

> Le 23/05/2013 15:59, Philip Martin a écrit :
>
> HOUDROGE Rami 
>  writes:
>
>> I am experiencing a problem that has been reported a couple of times
>> accross the web.
>>
>> 1. new file
>> 2. add file
>> 3. commit file
>> 4. lock file
>> 5. modify file
>> 6. commit file
>>
>> and that last commit fails with the following error :
>>
>> Cannot verify lock on path '...'; no matching lock-token available.
>>
>> [cid:part1.03020408.00020306@thalesgroup.com]
>>
>> I am certain no one stole the lock and I am also certain that,
>> locally, only one working copy has the lock.
>
> Run 'svn info' on the working copy file to see the lock token in the
> working copy.  Run 'svn info' on the URL to see the lock token in the
> repository.  How do the locks compare (token, username, date)?
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
>

On Thu, May 23, 2013 at 4:04 PM, HOUDROGE Rami
 wrote:
> They're the same.
>
> Local file :
> Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
> Lock Owner: houdroge
> Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)
>
> Remote file :
> Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
> Lock Owner: houdroge
> Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)
>
>

Rami,

Can you please try to reproduce this with commandline svn, and provide
us a full transcript of what you do to reproduce this (maybe with a
test file / test repository)? Or even better, a fully self-contained
reproduction script (I guess you're on Windows, so see [1] for a
template of a .bat reproduction script).

[1] http://subversion.apache.org/docs/community-guide/repro-template.bat

--
Johan

.

Re: Build on Pre-Commit

[Philip Martin]

San Martino  writes:

> I know that
> during the pre-commit phase the repository cannot be accessed concurrently,

That's not right.  The pre-commit runs before taking the repository lock
so other access, including other commits, can occur while the pre-commit
is running.  And that means that the pre-commit cannot guarantee
anything about files that are not part of the commit.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: SVN Error

[Thorsten Schöning]

Guten Tag Ajay Pawar,
am Freitag, 24. Mai 2013 um 12:16 schrieben Sie:

> I am able to access the repository through internet explorer but not through 
> tortoise svn client.

Then check the proxy settings of both, they may be different, with
different auth credentials or something like that.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: SVN Error

[Ajay Pawar]

I am able to access the repository through internet explorer but not through 
tortoise svn client.

-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de] 
Sent: Friday, May 24, 2013 3:31 PM
To: users@subversion.apache.org
Subject: Re: SVN Error

Guten Tag Ajay Pawar,
am Freitag, 24. Mai 2013 um 11:30 schrieben Sie:

> "OPTIONS of  Https://Hostname:port/svn/repoName : Could not create SSL 
> connection through Proxy Server :504 Gateway Timeout"

Did you access work before? There surely is some problem with your 
infrastructure, check your network connection to the proxy, that the proxy 
passes SSL communication properly etc.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 
207 694 - Geschäftsführer: Andreas Muchow

Re: Build on Pre-Commit

[Stefan Sperling]

On Fri, May 24, 2013 at 12:05:19PM +0200, San Martino wrote:
> We already use branches, but we use/justify them for developping long
> features or bug-fixes which require some time and are not urgent.
> In many cases, however, we must urgently fix small, short and important
> bugs and release everything immediatly.. We act on trunk directly for this
> and for this reason we shoule be sure that trunk is always ok. Opening a
> branch for each fix instead of using a validation on pre-commit makes the
> whole procedure more heavy does not guarantee that trunk is always in a
> "correct" state in any case.

The overhead isn't very high:

  svn checkout $TRUNK_URL my-fix
  cd my-fix

  edit files, test, build locally
  svn copy ^/trunk ^/branches/my-fix-branch
  svn switch ^/branches/my-fix-branch
  svn commit -m "commit my fix to a branch"

  my-fix-branch is tested / test fails
  edit files, test, build locally
  svn commit -m "fix the fix"

  my-fix-branch is tested / approved
  svn switch ^/trunk
  svn merge --reintegrate ^/branches/my-fix-branch
  svn commit -m "merge my-fix-branch to trunk"

In this example, the extra steps are a copy, two switches, and one merge.
Also, intermediate states of the fix are saved into the repository.

Conflicts during the reintegrate merge are unlikely because the
branch is short-lived. With your suggested approach, conflicts
aren't any less likely and would need to be dealt with during
updates of the trunk working copy.

BTW, with a Subversion 1.8 client, the step:

  svn merge --reintegrate ^/branches/my-fix-branch

becomes just:

  svn merge ^/branches/my-fix-branch

> While searching on internet I found two
> "Pre-Commit CI" :
> 
> http://www.pmease.com/features/continuous-integration.html#proof-build
> http://www.jetbrains.com/teamcity/features/delayed_commit.html
> 
> I have not read the documentation, but it appears they are near to what we
> want
> What do you think about them?

Sounds like tools that run a build based on a working copy with
some local changes applied to that working copy.

If your continuous integration software supports building a revision
plus local changes (e.g. in the form of patches submitted to the CI
software by the developer somehow), you could ask your developers to
perform such a test build before commit.

However, if your tooling isn't too complex to fit onto a single
developer machine, then I wonder where the advantage is over
having the developer run a local build before a commit.
Which generally is the expected behaviour of committers, anyway.

Re: Build on Pre-Commit

[San Martino]

We already use branches, but we use/justify them for developping long
features or bug-fixes which require some time and are not urgent.
In many cases, however, we must urgently fix small, short and important
bugs and release everything immediatly.. We act on trunk directly for this
and for this reason we shoule be sure that trunk is always ok. Opening a
branch for each fix instead of using a validation on pre-commit makes the
whole procedure more heavy does not guarantee that trunk is always in a
"correct" state in any case. While searching on internet I found two
"Pre-Commit CI" :

http://www.pmease.com/features/continuous-integration.html#proof-build
http://www.jetbrains.com/teamcity/features/delayed_commit.html

I have not read the documentation, but it appears they are near to what we
want
What do you think about them?


2013/5/24 Stefan Sperling 

> On Fri, May 24, 2013 at 10:14:04AM +0200, San Martino wrote:
> > Hello,
> >
> > I know this has been asked already, but we would really like to reject
> any
> > attempt to commit files which would break a project in trunk. The
> decision
> > to reject the committed files is based on the result of the building
> > process of the project the files being committed belong to. I know that
> > during the pre-commit phase the repository cannot be accessed
> concurrently,
> > but this is not a problem for us since our buildings are really fast and
> we
> > can tolerate any delay involved.
> >
> > Are there any tools to achieve what we want? Note that it will be
> necessary
> > ro recompile the whole project unit, not just the single files being
> > committed.
> >
> > Thanks.
>
> It sounds like you need a working copy for building.
> I don't think there is a way to construct a useful working copy
> from a transaction.
>
> You'd have to use some fragile construct such as a working copy
> of HEAD with local changes which are pulled from the transacion
> with the help of svnlook. This is inherently racy, because
> transactions run concurrently and HEAD could change during your
> test build.
>
> Essentially, doing what you have in mind really isn't supposed to be done.
>
> Instead, you could forbid direct commits to trunk, and only merge changes
> from branches that have been vetted. Have you considered that approach?
> Everything is transactional, and you always have a working trunk build.
> Your pre-commit hook could reject attempted commits to trunk which do
> not tweak svn:mergeinfo, and possibly even verify that the merge is
> merging changes from an approved branch by checking the mergeinfo and
> comparing it to a list of branches which may merge into trunk.
>

Re: SVN Error

[Thorsten Schöning]

Guten Tag Ajay Pawar,
am Freitag, 24. Mai 2013 um 11:30 schrieben Sie:

> “OPTIONS of  Https://Hostname:port/svn/repoName : Could not create
> SSL connection through Proxy Server :504 Gateway Timeout”

Did you access work before? There surely is some problem with your
infrastructure, check your network connection to the proxy, that the
proxy passes SSL communication properly etc.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

SVN Error

[Ajay Pawar]

HI team,

When I am trying to Accessing SVN Server through Tortoise SVN Repo browser, I 
faced the following issue.

"OPTIONS of Https://Hostname:port/svn/repoName : Could not create SSL 
connection through Proxy Server :504 Gateway Timeout"

Please help me.

Regrads,
Ajay Pawar

Re: subversion-1.8.0-rc2: diff_test 60 fails

[Philip Martin]

Branko Čibej  writes:

> On 24.05.2013 09:32, Tobias Bading wrote:
>> So, the update claims to have updated 3449_spurious to r2 and the
>> merge claims to have merged c4 into that file. As it turns out, both
>> claims seem correct. The contents of 3449_spurious look correct.
>> However, "svn status" and "svn diff" run afterwards both swear that
>> the only local modification of the working copy is a property change
>> at the wc root, the addition of the svn:mergeinfo property.
>>
>> Any idea what's going on here? What could affect the python script in
>> a way that its merge is messed up, although the same merge run by hand
>> works fine?
>
> Are you by any chance running the tests with the sleep for timestamps
> disabled? That could cause the effects you're seeing, especially
> combined with running on a FAT filesystem (which has 2-second timestamp
> granularity).

It does sound like a sleep/timestamp problem.  If you take a "broken"
working copy where the merge has changed 3449_spurious but status/diff
don't show it then running 'touch 3449_spurious' will change the
timestamp and should make status/diff work.

If the text change made by merge is not showing up in status it implies
that the preceeding update didn't sleep properly so we should be able to
confirm with this patch:

Index: subversion/tests/cmdline/diff_tests.py
===
--- subversion/tests/cmdline/diff_tests.py  (revision 1485754)
+++ subversion/tests/cmdline/diff_tests.py  (working copy)
@@ -3853,6 +3853,7 @@
 
   svntest.actions.run_and_verify_svn(None, None, [],
  'update', '-r2', wc_dir)
+  from time import sleep;sleep(2)
   svntest.actions.run_and_verify_svn(None, None, [],
  'merge', '-c4', '^/', wc_dir)

However this test explictly re-enables sleeping so the test should work
without that explicit sleep.  What filesystem are you using?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Build on Pre-Commit

[Stefan Sperling]

On Fri, May 24, 2013 at 10:14:04AM +0200, San Martino wrote:
> Hello,
> 
> I know this has been asked already, but we would really like to reject any
> attempt to commit files which would break a project in trunk. The decision
> to reject the committed files is based on the result of the building
> process of the project the files being committed belong to. I know that
> during the pre-commit phase the repository cannot be accessed concurrently,
> but this is not a problem for us since our buildings are really fast and we
> can tolerate any delay involved.
> 
> Are there any tools to achieve what we want? Note that it will be necessary
> ro recompile the whole project unit, not just the single files being
> committed.
> 
> Thanks.

It sounds like you need a working copy for building.
I don't think there is a way to construct a useful working copy
from a transaction.

You'd have to use some fragile construct such as a working copy
of HEAD with local changes which are pulled from the transacion
with the help of svnlook. This is inherently racy, because
transactions run concurrently and HEAD could change during your
test build.

Essentially, doing what you have in mind really isn't supposed to be done.

Instead, you could forbid direct commits to trunk, and only merge changes
from branches that have been vetted. Have you considered that approach?
Everything is transactional, and you always have a working trunk build.
Your pre-commit hook could reject attempted commits to trunk which do
not tweak svn:mergeinfo, and possibly even verify that the merge is
merging changes from an approved branch by checking the mergeinfo and
comparing it to a list of branches which may merge into trunk.

RE: svn AD authentication

[Stümpfig , Thomas]

Hi Pavel,
most users use tortoisesvn. What are the drawbacks of NTLM, SSPI, for 
Tortoisesvn users? I read some articles about 401 errors etc...
Also, I do not have the AD under control and it would not be easy for me to ask 
for changes in the AD. Btw. we are using the free version of Visualsvn and I 
hope to be able to test 1.8rc2 soon.

Thomas Stümpfig
Global Sales & Services

Siemens Industry Sector
Siemens Industry Software GmbH & Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 988
Mobile :+49 (175) 2205 712
thomas.stuemp...@siemens.com
www.siemens.com/plm

> -Original Message-
> From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com]
> Sent: Donnerstag, 23. Mai 2013 11:34
> To: Stümpfig, Thomas
> Cc: users@subversion.apache.org
> Subject: Re: svn AD authentication
>
> Hello Thomas,
>
> > are using svn in our company and authenticate against Microsoft Active
> > Directory. We are quite happy since years now.
> >
> > We are working worldwide and hence multi language. Some passwords may
> > have german umlaut, $, and other characters.
> >
> > Users that have these characters in their passwords do not
> > authenticate. Can anybody give me a hint where to start searching.
> >
> > (Apache, MS AD, OS).
>
> Non-ASCII symbols (e.g. '£', 'ü', 'ä' etc.) in password are not supported in 
> plain-
> text Basic Authentication. For details check this mailing list thread:
> http://mail-archives.apache.org/mod_mbox/subversion-
> users/201204.mbox/%3c87obqpxnis@stat.home.lan%3E
>
> In order to use special characters in passwords you should consider advanced
> authentication methods that do not store and transfer plain-text passwords
> over HTTP. As your network is based on Active Directory the solution would
> be to setup Single Sign-On / Integrated Windows AD authentication via
> Kerberos and/or NTLM.
>
> You may want to try VisualSVN Server Enterprise Edition that perfectly
> integrates in Active Directory and provides Single Sign-On out of the box
> without any additional configuration.
>
> Integrated Windows Authentication:
> http://www.visualsvn.com/server/features/windows-auth/#integrated
> VisualSVN Server Features list: http://www.visualsvn.com/server/features/
>
> Thank you.
>
> --
> With best regards,
> Pavel Lyalyakin
> VisualSVN Team
-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

Re: subversion-1.8.0-rc2: diff_test 60 fails

[Branko Čibej]

On 24.05.2013 09:32, Tobias Bading wrote:
> Hi Philip,
>
> thanks for your suggestions. I tried to dig a little deeper... and now
> things are getting even more strange.
>
> First, I tried to delete everything after the "update -r2" from
> no_spurious_conflict so I could make a copy of the wc before the
> merge. Guess what? Executing the "merge -c4 ^/" in a shell after
> running the test worked perfectly fine. So I removed the "update -r2"
> from no_spurious_conflict as well. Running "update -r2" and "merge -c4
> ^/" in a shell after the test worked perfectly fine again.
>
> Obviously, the test script does something differently than me in a
> shell. My python ain't that good, but I managed to come up with these
> lines:
>
>   exit_code, out, err = svntest.actions.run_and_verify_svn(None, None,
> [], 'update', '-r2', wc_dir)
>   print "update exit_code: ", exit_code
>   print "update out: ", out
>   print "update err: ", err
>   exit_code, out, err = svntest.actions.run_and_verify_svn(None, None,
> [], 'merge', '-c4', '^/', wc_dir)
>   print "merge exit_code: ", exit_code
>   print "merge out: ", out
>   print "merge err: ", err
>
> Now the test prints:
>
> update exit_code:  0
> update out:  ["Updating
> 'svn-test-work/working_copies/diff_tests-60':\n", 'U   
> svn-test-work/working_copies/diff_tests-60/3449_spurious\n', 'Updated
> to revision 2.\n']
> update err:  []
> merge exit_code:  0
> merge out:  ["--- Merging r4 into
> 'svn-test-work/working_copies/diff_tests-60':\n", 'U   
> svn-test-work/working_copies/diff_tests-60/3449_spurious\n', "---
> Recording mergeinfo for merge of r4 into
> 'svn-test-work/working_copies/diff_tests-60':\n", ' U  
> svn-test-work/working_copies/diff_tests-60\n']
> merge err:  []
>
> So, the update claims to have updated 3449_spurious to r2 and the
> merge claims to have merged c4 into that file. As it turns out, both
> claims seem correct. The contents of 3449_spurious look correct.
> However, "svn status" and "svn diff" run afterwards both swear that
> the only local modification of the working copy is a property change
> at the wc root, the addition of the svn:mergeinfo property.
>
> Any idea what's going on here? What could affect the python script in
> a way that its merge is messed up, although the same merge run by hand
> works fine?

Are you by any chance running the tests with the sleep for timestamps
disabled? That could cause the effects you're seeing, especially
combined with running on a FAT filesystem (which has 2-second timestamp
granularity).

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Build on Pre-Commit

[San Martino]

Hello,

I know this has been asked already, but we would really like to reject any
attempt to commit files which would break a project in trunk. The decision
to reject the committed files is based on the result of the building
process of the project the files being committed belong to. I know that
during the pre-commit phase the repository cannot be accessed concurrently,
but this is not a problem for us since our buildings are really fast and we
can tolerate any delay involved.

Are there any tools to achieve what we want? Note that it will be necessary
ro recompile the whole project unit, not just the single files being
committed.

Thanks.

Re: subversion-1.8.0-rc2: diff_test 60 fails

[Tobias Bading]

Hi Philip,

thanks for your suggestions. I tried to dig a little deeper... and now 
things are getting even more strange.


First, I tried to delete everything after the "update -r2" from 
no_spurious_conflict so I could make a copy of the wc before the merge. 
Guess what? Executing the "merge -c4 ^/" in a shell after running the 
test worked perfectly fine. So I removed the "update -r2" from 
no_spurious_conflict as well. Running "update -r2" and "merge -c4 ^/" in 
a shell after the test worked perfectly fine again.


Obviously, the test script does something differently than me in a 
shell. My python ain't that good, but I managed to come up with these lines:


  exit_code, out, err = svntest.actions.run_and_verify_svn(None, None, 
[], 'update', '-r2', wc_dir)

  print "update exit_code: ", exit_code
  print "update out: ", out
  print "update err: ", err
  exit_code, out, err = svntest.actions.run_and_verify_svn(None, None, 
[], 'merge', '-c4', '^/', wc_dir)

  print "merge exit_code: ", exit_code
  print "merge out: ", out
  print "merge err: ", err

Now the test prints:

update exit_code:  0
update out:  ["Updating 
'svn-test-work/working_copies/diff_tests-60':\n", 'U
svn-test-work/working_copies/diff_tests-60/3449_spurious\n', 'Updated to 
revision 2.\n']

update err:  []
merge exit_code:  0
merge out:  ["--- Merging r4 into 
'svn-test-work/working_copies/diff_tests-60':\n", 'U
svn-test-work/working_copies/diff_tests-60/3449_spurious\n', "--- 
Recording mergeinfo for merge of r4 into 
'svn-test-work/working_copies/diff_tests-60':\n", ' U   
svn-test-work/working_copies/diff_tests-60\n']

merge err:  []

So, the update claims to have updated 3449_spurious to r2 and the merge 
claims to have merged c4 into that file. As it turns out, both claims 
seem correct. The contents of 3449_spurious look correct. However, "svn 
status" and "svn diff" run afterwards both swear that the only local 
modification of the working copy is a property change at the wc root, 
the addition of the svn:mergeinfo property.


Any idea what's going on here? What could affect the python script in a 
way that its merge is messed up, although the same merge run by hand 
works fine?


I can provide a tarball containing the messed up working copy and the 
repository if you like.


Kind regards,
Tobias