Delay syncing to mirror repositories causing issues

[Simon]

We have a main master repository and a number of mirror slave repositories at a 
bunch of locations that are set up as webdav transparent write-through proxies. 
These are synced by a process similar to svnsync, and this all seems to work 
okay.

However, it is inevitable that there is delay in the commits at the master 
repository propagating out to the slaves. This is not usually a problem, except 
when a large commit has been made where the transfer time of the revisions data 
is significant. In this situation the a client that uses the slave repository 
can have its commit blocked because it is unable to update to the latest 
revision because the slave repository is out of sync. This is unfortunate 
because it makes the slave repository somewhat useless until the sync has time 
to resolve itself. In a recent situation our slave was out of sync for around 
3.5 hours.

Is there a workaround for this situation?
Switching the working copies back to the master is not really feasible at 
present because we run different UUIDs in the slave repositories, and I think 
our users would find this too cumbersome (or too complex!).

I was thinking that if the client had knowledge of the master repository 
(perhaps as an additional property in the slave repositories properties) it 
would be possible for it to defer back to the master for the updates under 
these circumstances.

I have a couple of other thoughts on this but I was wondering if anyone has 
some experience in this area?

Regard,

Simon

Re: Checkout fails on large repository

[Simon]

> Hello
> 
> I have a fairly large repository (~75 GB) containing mostly binary
> files (photos).
> When I try to do a checkout, it fails after checking out about 7.5 GB.
> 
> On the client, this error is shown:
> svn: REPORT of '/svn/photo/!svn/vcc/default': Could not read response
> body: Secure connection truncated (https://svn)
> svn co https://svn/svn/photo tdn-photos  1635,48s user 289,84s system
> 8% cpu 6:03:45,40 total
> 
> On the server, this error is written in the log:
> ==> /data/www/virtual/svn/log/error.log <==
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Provider
> encountered an error while streaming a REPORT response.  [500, #0]
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] A failure
> occurred while driving the update report editor  [500, #103]
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Error writing
> base64 data: Software caused connection abort  [500, #103]
> 
> ==> /data/www/virtual/svn/log/access.log <==
> 10.0.0.4 - tdn [11/Aug/2011:18:38:35 +0200] "REPORT
> /svn/photo/!svn/vcc/default HTTP/1.1" 200 4094599482 "-" "SVN/1.6.12
> (r955767) neon/0.29.5"
> 
> 
> I have tried turning off SSL and thus using regular HTTP instead of HTTPS.
> This did not fix the problem. I receive the same error.
> 
> I hope you can help me fix this problem.


Hi Thomas,

I've run into similar problems where the total commit size was large and the 
network speed to the server was slow (or blocked up). If the network link is 
not cleared fast enough this seems to cause things to timeout in the webdav 
layer. In our case it was actually write speed to NFS drives at the client end 
on our build farm that was slowing the whole process and backing up the network 
connection.

The simplest workaround we found was to restart the update as the client 
detects the failure and appears to clean up the working copy so that a restart 
is possible.

The following links describe what we ran into but we never really got a better 
solution rather than the above one I'm afraid:
  - http://sourceforge.net/apps/trac/sourceforge/ticket/1576
  - 
http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/<009501cac5d0$0e661140$2b3233c0$@qqmail.nl>

Hope this helps.

Simon

Automatic upgrade of wc format annoying on shared drives

[Simon]

We have work directories shared between many physical machines here (via sshfs, 
nfs, etc). We also use subversion as our configuration management system for 
source files.

When a newer client ends up on on of the work machines, it automatically (and 
silently) upgrades the wc metadata format of any working copies it touches. 
This prevents future access of any of the other clients until the working 
copies are manually downgraded (such as via: 
http://subversion.apache.org/faq.html#working-copy-format-change ).

This is quite annoying.

I think correct behaviour here is that the client should at least prompt the 
user to ask if it should upgrade the wc metadata format before messing with the 
working copy.

Failing that, is there some way of locking a working copy to a particular 
version of the wc metadata format.

Regards,

Simon

Re: Automatic upgrade of wc format annoying on shared drives

[Simon]

On 13/04/2010, at 18:46 , Daniel Shahaf d.s-at-daniel.shahaf.name | 
subversion users list| wrote:



Simon wrote on Tue, 13 Apr 2010 at 01:17 -:

I think correct behaviour here is that the client should at least
prompt the user to ask if it should upgrade the wc metadata format
before messing with the working copy.

Failing that, is there some way of locking a working copy to
a particular version of the wc metadata format.


Subversion 1.7 will require explicit user action to upgrade a wc.

% svn info wc1\trunk
...\..\..\subversion\libsvn_wc\upgrade.c:1086: (apr_err=155036)
svn: Working copy format of 'C:\tmp\svn\wc1\trunk' is too old (10);  
please run 'svn upgrade'




That's great. Thanks for the info.

Simon

[Patch] get-deps.sh fails to find sqlite-amalgamation

[Simon Olofsson]

Hi,

when trying to build SVN 1.6 from this branch:
 http://svn.apache.org/repos/asf/subversion/branches/1.6.x
get-deps.sh fails, because sqlite-amalgamation has been moved:

--2011-06-23 14:47:38-- 
http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz

Resolving www.sqlite.org... 67.18.92.124
Connecting to www.sqlite.org|67.18.92.124|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-06-23 14:47:39 ERROR 404: Not Found.

I fixed this by using the get-deps.sh script from trunk (with corrected 
versions of course). Here is the patch:

 http://pastebin.com/9kxS7M64

Should I create an issue?

Thanks
Simon

Re: Delay syncing to mirror repositories causing issues

[Simon Takita]

On 15/08/2011, at 23:30 , Nico Kadel-Garcia nkadel-at-gmail.com |subversion 
users list| wrote:
> This is *precisely* the situation I warned about last week? When
> someone else was trying to set up that kind of live mirror pretending
> to be a master-master setup. I'm quite 3.5 hours is impressive,
> though. How did that happen, if you don't mind giving more detail.
Essentially we run one master and use hook scripts to sync out to the remote 
slave servers. In this instance there was a ~700Mb binary blob checked in to 
the master. The 3.5 hour delay was predominately transfer time of the 700Mb 
transaction set across our loaded inter-office link.

Re: Delay syncing to mirror repositories causing issues

[Simon Takita]

On 15/08/2011, at 22:54 , Stefan Sperling stsp-at-elego.de |subversion users 
list| wrote:

> On Mon, Aug 15, 2011 at 01:34:15AM +0000, Simon wrote:
>> We have a main master repository and a number of mirror slave
>> repositories at a bunch of locations that are set up as webdav
>> transparent write-through proxies. These are synced by a process
>> similar to svnsync, and this all seems to work okay.
> 
> So you're using a different synchronisation process than svnsync?
> How does it work? What prevents you from using svnsync? What's the
> commit-transfer latency of your procedure compared to the latency of svnsync?
Our sync mechanism essentially uses svnadmin dump at the master and svnadmin 
load at the slaves with some home cooked supervisory functionality to gel it 
all together. This may not be optimal but my understanding is that our sync 
mechanism was developed to work around some prior problems in svnsync for large 
commits. It is possible that the original svnsync problem has long since been 
fixed but the infrastructure is now somewhat standardised and I have very 
limited control over the infrastructure that I have available.

>> However, it is inevitable that there is delay in the commits at the
>> master repository propagating out to the slaves. This is not usually a
>> problem, except when a large commit has been made where the transfer
>> time of the revisions data is significant. In this situation the a
>> client that uses the slave repository can have its commit blocked
>> because it is unable to update to the latest revision because the
>> slave repository is out of sync. This is unfortunate because it makes
>> the slave repository somewhat useless until the sync has time to
>> resolve itself. In a recent situation our slave was out of sync for
>> around 3.5 hours.
>> 
>> Is there a workaround for this situation?
> 
> You're not telling why one or more commits took 3.5 hours to sync.
> Why was the date set larger than usual? Maybe if you provide more
> information about this someone will come up with a workaround.
This was a 700Mb checkin synced out to slaves over a loaded WAN link, so this 
was predominately transfer time of the data blob for the commit.


> One scenario where a large commit can happen is when a lot of new
> revisions are imported from a dumpfile, e.g. when a project is moved
> from one repository to another.
> The Apache Software Foundation (ASF) uses a write-through proxy setup.
> The main server is in the US and the mirror is in Europe. Occasionally,
> new code is imported with history when a project joins the ASF. 
> The new revisions are stored in a dump file which is copied to the master
> and the slave. Next, commit access is temporarily disabled on both servers.
> The dump file is loaded into both repositories. svnsync meta data is updated
> on the slave to mark the current head revision as synced (this number
> is in the svn:sync-last-merged-rev revision property at revision 0). 
> Now when commit access is re-enabled the master and slave are already
> in sync. The resulting downtime is lower than if the newly imported
> revisions were imported at the master and synced via svnsync.

Re: Delay syncing to mirror repositories causing issues

[Simon Takita]

On 16/08/2011, at 02:34 , Stefan Sperling stsp-at-elego.de |subversion users 
list| wrote:

> On Mon, Aug 15, 2011 at 11:06:29AM -0500, Les Mikesell wrote:
>> I suppose the direct access could help in the case where the
>> revision taking too long to sync is not the same data the client
>> needs for its update, but otherwise it could make things worse.
> 
> Good point.
> 
> I was thinking of operations like 'svn log', 'svn diff' etc.
> An update will need to pull the same data the sync is getting, of course.


Direct access would certainly help in the case where the revision in transit 
was unrelated to a clients working copy. In fact I would probably expect this 
to be the usual case.

Even though deferring to the master in this case (where the transaction is 
related to the working copy), could make things worse in terms of absolute sync 
time, the current situation is that the slave can't be used for some operations 
during this period. In our situation fully coherent access to what the master 
server sees is a higher priority than update time, but I understand that others 
may have a different priority here.

Subversion Exception!

[Simon Hughes]

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

(users@subversion.apache.org)

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

 

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

 

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion
\libsvn_wc\workqueue.c'

line 672: assertion failed (checksum != NULL)

---

OK   

---

 

Steps to reproduce:

1.   Upgraded my local SVN repo to v1.7

2.   Did some modifications to some files.

3.   Check in dialog

4.   Press OK, got error.

 

Regards,

Simon Hughes

Lead Software Developer

 

   ByBox Holdings Ltd | M: 07768 987393

E: simon.hug...@bybox.com <mailto:simon.hug...@bybox.com> 

W: www.bybox.com <http://www.bybox.com/> 

 

<>

Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

Hi 

Are there any plans to add a command to SVN that cleans a working copy or path 
of all unversioned and/or ignored files and directories?  

This is a very common need for automated Continuous Integration builds where a 
working copy is reused for multiple runs of the same build.  Currently there is 
no simple and fast way to restore a working copy to a prestine state.  Often 
users have to choose between i) completely deleting the working copy for every 
build and then doing a fresh checkout from scratch or ii) living with lots of 
unversioned and ignored files and directories building up with each successive 
build.  

The only option at the moment is to write a shell/batch script to provide this 
feature which is messy and there's common way to do this.  A new SVN command or 
enhanced exiting command that provided this functionality would be incredibly 
useful.  

As an example, here is the DOS batch script that I use at the moment: 

@echo off
:: revert any uncommitted changes
svn revert . --recursive

:: remove all unversioned and all ignored files and directories
for /f "usebackq tokens=1*" %%i in (`svn status --depth infinity 
--no-ignore ^| findstr /r "^[\?I]"`) do ( 
  if not %%j == %~nx0 (
if exist "%%j\*" (
  echo deleting unversioned directory "%%j"
  attrib -h "%%j" /d /s
  rmdir /s /q "%%j"
) else (
  echo deleting unversioned file "%%j"
  attrib -h "%%j"
  del /f "%%j"
)
  )
)

A possible command line syntax might look something like this: 

svn revert . --ignored --unversioned --recursive



Many thanks
Simon Dean

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysupermarket.com Financial Group Limited, registered in England No. 
3157344. 
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. 
Telephone 01244 665700.

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
>
> Sorry, but to me this has got nothing to do with Subversion. Your CI 
> tool is should clean up itself.
> 
> Having said that, if someone wants to implement such feature I don't 
> think I would have anything against it. But I doubt it will (be 
> implemented)
> 
> Giulio

Thanks for the reply.  There are 5 or 6 popular CI tools out there (and there's 
probably more of them than that).  If implemented in the CI tool, each tool 
would have to implement it for themselves.  

Plus a CI tool would have to implement a separate solution for each VCS it 
supports (e.g. git, perforce, mercurial etc).  

As this is a feature that requires an SVN specific implementation and isn't a 
feature specific to CI builds - it's just a feature to restore a working copy 
to pristine state - SVN seems like a good place for it?  

I suspect developers would also benefit from such a feature on their 
development PCs too and not just on CI servers?  

Kind regards
Simon

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysupermarket.com Financial Group Limited, registered in England No. 
3157344. 
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. 
Telephone 01244 665700.

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> From: Bob Archer [mailto:bob.arc...@amsi.com]
> 
> FYI: If you are on windows the TortoiseSVN client's "Clean up" function
> allows you to delete unversioned and ignored files if you want. Also, it 
> allows
> you to revert all changes when you clean up as well.
> 
> BOb
> 

TortoiseSVN feature is very good.  Unfortunately it only seems available 
through its GUI and not through it's command line.  

Here's a quick sample of various people trying to accomplish this feature for 
themselves through various scripts etc.  


http://stackoverflow.com/questions/9082706/using-powershell-and-svn-to-delete-unversioned-files
 

http://www.guyrutenberg.com/2008/01/18/delete-unversioned-files-under-svn/

http://stackoverflow.com/questions/2803823/how-can-i-delete-all-unversioned-ignored-files-folders-in-my-working-copy

http://patforna.blogspot.com/2009/10/remove-unversioned-files-in-subversion.html

Simon

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysupermarket.com Financial Group Limited, registered in England No. 
3157344. 
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. 
Telephone 01244 665700.

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
> 
> Why would the CI implement a different solution for each VCS? Those, I
> understand, are files created during the build process, they have got nothing
> to do with SVN or any other VCS. And it's not a SVN specific implementation
> as, again, the files were not created by SVN so they've got nothing to do with
> it.
> 
>  From Subversion's point of view the the WC is absolutely fine. The
> unversioned files are ignore and there are no missing files (and if there are 
> a
> simple svn up will restore them)
> 
> But maybe I'm missing something?

A CI implementation would have to implement it specifically each VCS as it 
would have to call the VCS to found out what files/directories are unversioned 
and ignored.  

Interestingly TortoiseSVN also implements the same feature (as Bob Archer 
highlights).  This is a good example of the same feature being used for non-CI 
purposes.  Unfortunately the TortoiseSVN implementation is both Windows 
specific and not available from the command line.  

It is helpful though to see how TortoiseSVN describes the feature (quoted from 
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-cleanup.html) 

Delete unversioned files and folders, Delete ignored files and folders
==

This is a fast and easy way to remove all generated files in your 
working copy. All files and folders that are not versioned are moved to the 
trash bin.

Note: you can also do the same from the TortoiseSVN → Revert dialog. 
There you also get a list of all the unversioned files and folders to select 
for removal.

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysupermarket.com Financial Group Limited, registered in England No. 
3157344. 
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. 
Telephone 01244 665700.

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> -Original Message-
> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
> So the CI would rely on another piece of software, SVN in this case, to know
> what it has created in terms of files. Well, it doesn't seem right to me.

With TortoiseSVN providing this functionality through a GUI to end-users, I 
guess the discussion of whether such a feature should be implemented in a CI 
tool or in the SVN client is a moot point. 
Either way, I think we'll have to agree to disagree.  

Kind regards 
Simon 

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might affect any computer or system into which they are 
received and opened, it is the responsibility of the recipient to ensure that 
they are virus free and no responsibility is accepted by Moneysupermarket.com 
Financial Group Limited for any loss or damage from receipt or use thereof. 
The views expressed are of the individual, and do not necessarily reflect the 
views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of 
Moneysupermarket.com Financial Group Limited, which is authorised and regulated 
by the Financial Services Authority (FSA FRN 303190). 
Moneysupermarket.com Financial Group Limited, registered in England No. 
3157344. 
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. 
Telephone 01244 665700.

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

I suspect TortoiseSVN uses the official Subversion client code under the hood.  
There's no way they'd re-implement a whole SVN client from scratch.  

Not many third-party SVN clients (any?) implement the SVN client-side 
implementation themselves.  They use SVN libraries for that - something like 
SVNKit (http://svnkit.com/) 

In fact, the Subverson project discourages other clients from directly 
manipulating the contents of the .svn directory.  To quote 
http://subversion.apache.org/docs/release-notes/1.7.html: 

"Subversion 1.7 working copies have just one .svn directory...This 
directory includes (among other things) an SQLite-backed database which 
contains all of the metadata Subversion needs for that working copy...We highly 
discourage external tools from modifying the data held in this database, as 
such modification is likely to result in working copy corruption."

Other people have commented on the fragility of the "clean" task of a build 
script.  If you use things like NuGet and Bundler in codebases, they result in 
multiple directories that need "cleaning" - e.g. .\vendor\bundle, .\packages 
etc.  You'd be surprised how many unversioned files creep into a CI build when 
all you're relying on is the build script's "clean" task

> -Original Message-
> From: David Weintraub [mailto:qazw...@gmail.com]
> Sent: 12 March 2012 16:33
> To: Nico Kadel-Garcia
> Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; Simon Dean;
> users@subversion.apache.org
> Subject: Re: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
> 
> Here's why I don't think this is a feature for the Subversion project:
> 
> * This is a Subversion client function and not a function of Subversion 
> itself.
> Subversion thoughtfully publishes a Subversion API that developers can use
> to create their own Subversion clients. Notice that TortoiseSVN does not
> require a Subversion command line client unlike TortoiseCVS that requires a
> CVS command line client. Notice that Eclipse and AnkhSvn don't require a
> Subversion command line client.  Anyone can create a Subversion client with
> the API, and if they choose, can create this type of functionality. Even if 
> you
> put this functionality in the Subversion command line client, Subversion
> clients that use the API might not have it.
> 
> * Many continuous integration systems (like Jenkins) already have an option
> to remove non-versioned files before doing a build. The OP mentioned this
> as an issue.
> 
> * It is traditional when you design your build system to make sure your built
> objects are stored in a temporary directory, so they don't pollute your source
> area. This way, it's easy to remove all of your built objects by simply 
> deleting
> the temporary folder. In Java, I tell developers to create a folder called
> "target" under their project root, and store all built files and logs over 
> there.
> This also ensures that you don't accidentally add built files into your
> repository.
> 
> * It is traditional as part of your build system to have a "clean"
> target that does this.
> 
> * It is easy enough to create a script to do this job for you. In Unix, if you
> don't have spaces in your file names, the one liner "svn status | awk '/^\?/
> {print $2}' | xargs rm -rf" will do the job.
> 
> * There are more serious features that Subversion is missing. The best
> known is a true "obliterate" command to remove obsolete revisions of files.
> For example, if someone commits a file that contains customer proprietary
> information, there's no easy way to completely remove that revision from
> Subversion. You have to take down the repository, and do a dump, filter, and
> load. I'd rather the Subversion team work on this issue, which involves the
> way the Subversion server acts, rather than this issue.
> 
> This maybe why this has never even been considered as a feature. It really
> doesn't affect Subversion itself.  This is something that the build system
> should be handling. In many open source projects, the source and build files
> are tarred up and distributed. What happens when the source is distributed,
> and you can't depend upon the version control system to do this for you?
> 
> Nico Kadel-Garcia commented that this is important because his build
> contains many war files. You really should never check in built objects into
> Subversion. Instead, these objects should be stored in a release system
> where they can be downloaded as needed. Maven does this, but you can
> easily do this with Ant and Ivy too. Storing wars and jars in version contro

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

Not having contributed to SVN before, I don't really know how the SVN client(s) 
are implemented.  How much of the code in the various Windows and Linux SVN 
command line clients (e.g. CollabNet's Windows command line client, SlikSVN's 
Windows command line client, TortoiseSVN's svn.exe etc) comes from the codebase 
that Apache now manage and how much is unique to each client?  

Is it the Subversion API that provides the bulk of their various clients' 
functionality?  What keeps the command arguments etc. of the various clients 
the same?  

Thanks 
Simon 


> -Original Message-
> From: Simon Dean
> Sent: 12 March 2012 17:05
> To: 'David Weintraub'; Nico Kadel-Garcia
> Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; users@subversion.apache.org
> Subject: RE: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
> 
> I suspect TortoiseSVN uses the official Subversion client code under the
> hood.  There's no way they'd re-implement a whole SVN client from scratch.
> 
> Not many third-party SVN clients (any?) implement the SVN client-side
> implementation themselves.  They use SVN libraries for that - something like
> SVNKit (http://svnkit.com/)
> 
> In fact, the Subverson project discourages other clients from directly
> manipulating the contents of the .svn directory.  To quote
> http://subversion.apache.org/docs/release-notes/1.7.html:
> 
>   "Subversion 1.7 working copies have just one .svn directory...This
> directory includes (among other things) an SQLite-backed database which
> contains all of the metadata Subversion needs for that working copy...We
> highly discourage external tools from modifying the data held in this
> database, as such modification is likely to result in working copy 
> corruption."
> 
> Other people have commented on the fragility of the "clean" task of a build
> script.  If you use things like NuGet and Bundler in codebases, they result in
> multiple directories that need "cleaning" - e.g. .\vendor\bundle, .\packages
> etc.  You'd be surprised how many unversioned files creep into a CI build
> when all you're relying on is the build script's "clean" task
> 
> > -Original Message-
> > From: David Weintraub [mailto:qazw...@gmail.com]
> > Sent: 12 March 2012 16:33
> > To: Nico Kadel-Garcia
> > Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; Simon Dean;
> > users@subversion.apache.org
> > Subject: Re: Feature request - SVN command to clean a working copy of
> > all unversioned and ignored files and directories
> >
> > Here's why I don't think this is a feature for the Subversion project:
> >
> > * This is a Subversion client function and not a function of Subversion 
> > itself.
> > Subversion thoughtfully publishes a Subversion API that developers can
> > use to create their own Subversion clients. Notice that TortoiseSVN
> > does not require a Subversion command line client unlike TortoiseCVS
> > that requires a CVS command line client. Notice that Eclipse and
> > AnkhSvn don't require a Subversion command line client.  Anyone can
> > create a Subversion client with the API, and if they choose, can
> > create this type of functionality. Even if you put this functionality
> > in the Subversion command line client, Subversion clients that use the API
> might not have it.
> >
> > * Many continuous integration systems (like Jenkins) already have an
> > option to remove non-versioned files before doing a build. The OP
> > mentioned this as an issue.
> >
> > * It is traditional when you design your build system to make sure
> > your built objects are stored in a temporary directory, so they don't
> > pollute your source area. This way, it's easy to remove all of your
> > built objects by simply deleting the temporary folder. In Java, I tell
> > developers to create a folder called "target" under their project root, and
> store all built files and logs over there.
> > This also ensures that you don't accidentally add built files into
> > your repository.
> >
> > * It is traditional as part of your build system to have a "clean"
> > target that does this.
> >
> > * It is easy enough to create a script to do this job for you. In
> > Unix, if you don't have spaces in your file names, the one liner "svn
> > status | awk '/^\?/ {print $2}' | xargs rm -rf" will do the job.
> >
> > * There are more serious features that Subversion is missing. The best
> > known is a true "obliterate&

RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

[Simon Dean]

> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: 14 March 2012 10:46
> To: 'David Weintraub'; Simon Dean
> Cc: 'Nico Kadel-Garcia'; 'Les Mikesell'; 'Andreas Krey'; 'Giulio Troccoli';
> users@subversion.apache.org
> Subject: RE: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
> 
> > -Original Message-
> > From: David Weintraub [mailto:qazw...@gmail.com]
> > Sent: woensdag 14 maart 2012 2:14
> > To: Simon Dean
> > Cc: Nico Kadel-Garcia; Les Mikesell; Andreas Krey; Giulio Troccoli;
> > users@subversion.apache.org
> > Subject: Re: Feature request - SVN command to clean a working copy of
> > all unversioned and ignored files and directories
> >
> > On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean
> >  wrote:
> > > I suspect TortoiseSVN uses the official Subversion client code under
> > > the
> > hood.  There's no way they'd
> > >  re-implement a whole SVN client from scratch.
> >
> > I don't know if Tortoise uses any Subversion command line client code,
> > but TortoiseSVN does use the official Subversion API libraries. That's
> > what made Subversion so different from CVS. With CVS, you either had
> > to reimplement the client yourself, or use the offical CVS client as a
> > backend. In Subversion you write your own client, and just use the
> > API.
> >
> > SVNKit is very different. SVNKit is a Java third party
> > reimplementation of the Subversion API, and it's not the complete API
> > either. On the other hand, the JavaHL API is a front end to the
> > official Subversion API.
> >
> > So, it's possible for someone to write a Subversion client that does
> > do a "clean up". In fact, the Jenkins Continuous build system has the
> > option of doing a thorough clean before doing an update.
> >
> > > Other people have commented on the fragility of the "clean" task of
> > > a
> build
> > script.  If you use things like NuGet
> > > and Bundler in codebases, they result in multiple directories that
> > > need
> > "cleaning" - e.g. .\vendor\bundle,
> > >  .\packages etc.  You'd be surprised how many unversioned files
> > > creep
> into a CI
> > build when all you're relying
> > > on is the build script's "clean" task
> >
> > For some reason, the .NET/C# world is behind in this concept when
> > compared to the Java world.  By default, there's a "clean" target in
> > VisualStudio builds, but it doesn't do a very good job of cleaning.
> 
> The standard files produced by Visual Studio should clean up everything, but
> if you customize your build you should also customize the cleanup. (This
> assumes that you pass the same custom variables to the build as the cleanup
> step of MSBuild. If not it cleans up a different build)
> 
> And Visual Studio makes adding custom build tasks very easy, but doesn't
> provide an easy way to add your own cleanup tasks. (I see too many scripts
> that just call things like xcopy and assume this magically cleans up)
> 
> 
> When running from Visual Studio it appears that there are leftovers, but this
> is mostly because the Intellisense uses the same infrastructure to get its
> information.
> 
> 
> 
> If you do find places where the common tasks leave files behind please
> report them as Microsoft is still taking bug reports for Visual Studio 11.
> 
> And if these are Subversion and/or AnkhSVN specific problems please also
> send me a mail so I might be able to reach out via a few other channels.
> 
>   Bert
> 

I use Rake and Gradle (migrated to Gradle from Maven).  Rake is used for .NET 
codebases and Gradle for Java.   It's very easy for files to slip through a 
"clean" task.  Problem is, a "clean" task doesn't "fail fast"  (an agile 
principle which is also a more general principle: 
http://en.wikipedia.org/wiki/Fail-fast) 

-
The information contained in this message may be CONFIDENTIAL and is intended 
for the addressee only. Any unauthorised use, dissemination of the information, 
or copying of this message is prohibited. If you are not the addressee, please 
notify the sender immediately by return e-mail and delete this message. 
Although this e-mail and any attachments are believed to be free of any virus, 
or other defect which might af

"Commit to Subversion" dialog, cannot use keyboard to get out of Log Message control.

[Simon Crossley]

On the "Commit to Subversion" dialog, if the Log Message control has focus, I 
cannot use the keyboard to get out of the control (I cannot use either Tab or 
Enter) - I have to use the mouse to get out.

Could you please add a shortcut to the OK button (just change the text of the 
control to "&OK").

Thanks!

Re: Cleanup needed after failed update

[Simon Large]

Johan Corveleyn  gmail.com> writes:
> 'svn cleanup' removes any working copy locks, and runs whatever is
> left in the work_queue, thereby returning the working copy to a valid
> state.
> 
> BTW, the work of moving the file into place has some sort of
> "retry-loop", where it keeps retrying for a couple of seconds (to
> account for anti-virus scanners and such, where the file is locked for
> only a short time). But it can't keep waiting forever, so if the file
> is locked for a long time, "update" will have to give up.

One thing which could help in this case, rather than just retrying for N 
seconds 
would be to provide a callback function so that a GUI client like TSVN could 
display a message saying that file X is already open, giving you a chance to 
close it and retry the operation.

Simon

Pristiine copy not present

[Simon Heffer]

We seem to have a deadlock of some kind...
At the end of a system build we commit our built components to a binary 
repository...

svn cleanup --username x --password x

svn commit -m "build msg" --username x --password 
svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe' not 
present
svn: E155004: Commit failed (details follow):
svn: E155004: Working copy 'D:\xx\Base' locked.
svn: E155004: 'D:\x\Base' is already locked.
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

If I run svn cleanup again I get:
svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe' not 
present

or update:
svn update
svn: E155004: Working copy 'D:\xx\Base' locked.
svn: E155004: 'D:\x\Base' is already locked.
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

The working copy is quite new i.e. not much opportunity to screw it up :(


Simon Heffer


Please consider the environment before printing this e-mail.

Micro Focus Limited is registered in England and Wales. Registered number: 
01504593 Registered office: The Lawn, 22-30 Old Bath Road Newbury, Berkshire, 
RG14 1QN, UK
This message has been scanned by MailController - portal1.mailcontroller.co.uk

RE: Pristiine copy not present

[Simon Heffer]

Thanks all,

svn --version gives:
svn, version 1.7.2 (r1207936)
   compiled Nov 29 2011, 22:11:27

There's no build system issue here. We build a number of different machines 
(windows and UNIXs) and copy the results onto the final machine (Windows Server 
2003 SP2). A script is then run to copy the files into the working copy and 
another to commit to the repository. This system has been in place for over 
three years.

I have checked out a clean copy already to try and fix this but still get the 
same problem. Those messages are what we get.

Unlikely I'll be able to poke around too much on this system as it's used to 
control all our production builds but I'll see what's possible. We do have SQL 
server 2005 installed - is there a way to use that?

Simon

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: 24 August 2012 20:59
To: Simon Heffer
Cc: Daniel Shahaf; Bert Huijben; users@subversion.apache.org
Subject: Re: Pristiine copy not present

On Fri, Aug 24, 2012 at 7:12 PM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>> Sent: vrijdag 24 augustus 2012 18:32
>> To: Simon Heffer
>> Cc: users@subversion.apache.org
>> Subject: Re: Pristiine copy not present
>>
>> Simon Heffer wrote on Fri, Aug 24, 2012 at 15:55:29 +:
>> >
>> > We seem to have a deadlock of some kind...
>> > At the end of a system build we commit our built components to a 
>> > binary
>> repository...
>> >
>> > svn cleanup --username x --password x
>> >
>>
>> Last I checked, 'cleanup' does not access the repository (well, maybe 
>> except for upgraded 1.0 working copies or something like that, Bert 
>> would know :)), so it doesn't need these arguments.
>
> svn upgrade needs access to the repository for 1.0 working copies, but 
> svn cleanup never.
> (Very early in 1.7 development we used svn cleanup for the upgrade, 
> but we never released that code)
>
>> > svn commit -m "build msg" --username x --password 
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> > svn: E155004: Commit failed (details follow):
>> > svn: E155004: Working copy 'D:\xx\Base' locked.
>> > svn: E155004: 'D:\x\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > If I run svn cleanup again I get:
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> >
>> > or update:
>> > svn update
>> > svn: E155004: Working copy 'D:\xx\Base' locked.
>> > svn: E155004: 'D:\x\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > The working copy is quite new i.e. not much opportunity to screw it 
>> > up
> :(
>
> Which build system do you use?
>
> Some very popular java based buildsystems automatically use svnkit, 
> and in that case we might have to call in others to help in diagnosinroblem.

Indeed, I've seen similar issues after svnkit usage (though I believe they 
fixed some subtle corruption bugs in their most recent release (1.7.5-v1)). It 
would be nice if you could confirm if svnkit is involved (has ever been used on 
this working copy), and if so, which version. I've never seen 
'pristine-text-not-present' problems with only native svn usage.

Now, if you want to repair this working copy, and you're feeling adventurous, 
here is something you can try (I've had some success with this, but YMMV -- 
WARNING: this involves direct manipulation of the working copy metadata. If 
something goes wrong you might destroy your working copy):

1) Get an sqlite executable (for Windows: download a pre-compiled binary from 
http://www.sqlite.com/download.html). Put it somewhere in your PATH.

2) Open a command prompt and go to the root of your working copy. Execute:

sqlite3 .svn\wc.db "select * from nodes where checksum like 
'%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

This should return exactly 1 row from the svn working copy database.
You can see in that row the local path that's related to that pristine file.

3) Now execute:

sqlite3 .svn\wc.db "update nodes set presence='not-present' where checksum like 
'%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

Now you've changed the presence value of that particular row to "not-present", 
giving svn a

RE: Pristiine copy not present

[Simon Heffer]

Hi,
So some small progress made by using yet another fresh checkout.
Now I'm getting:

svn: E20: Commit succeeded, but other errors follow:
svn: E720005: Error bumping revisions post-commit (details follow):
svn: E720005: Can't set file '' read-write: Access denied

Is this access in to the wc.db file or the pristine folders it cannot access?

svn info  gives:

svn: E155037: Previous operation has not finished; run 'cleanup' if it was inter
rupted


Simon
This message has been scanned by MailController - portal1.mailcontroller.co.uk

RE: Pristiine copy not present

[Simon Heffer]

>I think that's the permissions of the actual on-disk file (and the directory 
>that contains it).  It's a bit hard to tell without knowing whether the error 
>message mentioned a >versioned file or a file under the .svn dir.

It's a versioned file. It does look like a permissions problem but I'm 
struggling to see what's changed in that regard.

Thanks anyway,
Simon
This message has been scanned by MailController - portal1.mailcontroller.co.uk

mailer.conf question

[Simon Butler]

I'd like to send emails to different aliases based on the repository
location of a checked in file. i have my postcommit hook and mailer.py setup
fine and added the following section to my mailer.conf file

[docs]
for_paths = https://svn.tt-da.com/mdx/docs/*
# # set a custom prefix
commit_subject_prefix = [MDX Docs Change]
# # override the default, sending these elsewhere
to_addr = sa...@tt-da.com
# # use the revision author as the from address
from_addr =

 unfortunately I don't seem to get any different behavior (than just sending
email to the default developers alias) when i commit a file

--

svn python bindings

[Simon Butler]

We installed Subversion (SVN) 1.5 from CollabNet on CentOS 4 and are looking
for the Python binding to the client-side SVN programming interface (API).

The obvious choice would be PySVN from .  However,
since no pre-builts package for RedHat or CentOS are available, we need to
build PySVN from source.

To do so, at least one include file svn_client.h is required, plus a number
of libraries and perhaps more.  Those seem to be missing from the CollabNer
SVN release.

Our question is, is any Python binding available for CollabNet's SVN 1.5?
 Or, how can the PySVN binding be built with CollabNet's SVN 1.5?

--

fixing files committed with wrong eol-style

[Kitching, Simon]

Hi,

 

We've got a repository containing a lot of text-files committed from
windows systems without the svn:eol-style=native setting. Some
developers now want to work on these from Linux.

 

I would therefore like to fix the eol-style. Writing a script on linux
to find all the relevant files and run "propset svn:eol-style native" on
them is easy enough. However I've noticed that if the change is
committed from *linux*, then the commit not only changes the file
properties, but also *every line-ending in the file*, ie looking at
diffs between files before and after this change is now pointless.
Committing exactly the same propset change from *windows* just sets the
property without the whitespace problems; checking out on both systems
then works as expected, and diffs between repository versions are sane.

 

However it's much more convenient to write and run this script from
linux. Is there any way from linux to persuade subversion to just set
the eol-style property?

 

Thanks,

Simon

Good planets are hard to find - please think of the environment before you 
print this email.

CAUTION - This message may contain privileged and confidential 
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby 
notified that any use, dissemination, distribution or reproduction 
of this message is prohibited. If you have received this message in 
error please notify Air New Zealand immediately. Any views expressed 
in this message are those of the individual sender and may not 
necessarily reflect the views of Air New Zealand.
_
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com 
_

Re: Re: fixing files committed with wrong eol-style

[Kitching, Simon]

Hi David et al.,

On Mon, Jul 12, 2010 at 10:58 PM, Kitching, Simon
> > We've got a repository containing a lot of text-files committed from windows
> > systems without the svn:eol-style=native setting. Some developers now want
> > to work on these from Linux.
> >
> >
> >
> > I would therefore like to fix the eol-style. Writing a script on linux to
> > find all the relevant files and run propset svn:eol-style native on them
> > is easy enough. However I've noticed that if the change is committed from
> > *linux*, then the commit not only changes the file properties, but also
> > *every line-ending in the file*, ie looking at diffs between files before
> > and after this change is now pointless. Committing exactly the same propset
> > change from *windows* just sets the property without the whitespace
> > problems; checking out on both systems then works as expected, and diffs
> > between repository versions are sane.
> >
> >
> >
> > However it's much more convenient to write and run this script from linux.
> > Is there any way from linux to persuade subversion to just set the eol-style
> > property?
> >
> 
On Wed, 2010-07-14 at 10:35 -0400, David Weintraub wrote:
> I have a pre-commit hook that will verify that particular files have
> svn:eol-style set before allowing a commit. This way, you can make
> sure that the property is set before anyone can do a commit.

Yes, that might be the best way to prevent the problem reoccurring in
the future. Unfortunately, it doesn't help with fixing a pre-existing
repository (ie setting eol:style=native on existing files that really
should have had it set when they were created but didn't).

> 
> What IDE are you using? If you're not using an IDE, what program
> editor are you using. Please, tell me, for the sake of everything we
> hold dear, that your developers aren't using Notepad for editing their
> files. Please tell me they're not.

No, developers here are using Eclipse on Windows or Eclipse on Linux.

> 
> Your developers on your Windows side need a good program editor. A
> good program editor handles various line endings with aplomb. That
> means it doesn't matter if a file has either Windows or Unix style
> line endings. The text editor will handle that and there is no need to
> convert from one to the other. In fact, your Linux developers should
> also be working with a similar editor.

The problem is not tools handling different line-endings. The problem is
that (without eol-style=native) all text files end up with a nasty mix
of line-endings; files added by devs using Windows have lines ending in
\r\n and files added by devs using linux have lines end in \n. It's not
the end of the world, but it's just not right.

Interestingly, Eclipse is smart enough to detect line-endings for
preexisting files, and uses the same line-ending style when editing that
file. But new files get the local OS defaults.

The correct answer is to set eol-style=native on the relevant files. But
SVN appears to have some weird behaviour that makes adding this property
to existing files much more difficult than it should be. AFAICT it is
only possible to *correctly* fix this issue from a Windows PC!

I've double-checked: setting svn:eol-style=native on all the relevant
files and then committing from windows works well. The history diffs
show just a property change, as expected. Unfortunately, writing scripts
on Windows to scan a directory and set the property isn't so easy (at
least for me); "find .. -exec svn propset ..." isn't an option :-(

And doing a find/exec + commit on linux to fix the problem causes
historical diffs to show that every line has changed :-(

Ah well, as it appears that nobody here knows the answer I'll just have
to do it the ugly way: try to get the svn repo administrator to install
some hooks to prevent this occurring in future, and then install cygwin
on somebody's windows PC to script the adding of eol-style=native to
relevant existing files.

> This gives me a visual diff, and I call it via:
> 
> $ svn diff --diff-cmd mydiff 
> 
> Here's what mydiff looks like:
> 
> #! /usr/bin/env perl
> 
> use strict;
> use warnings;
> 
> my $DIFF = "/usr/bin/vimdiff";
> 
> my $parameters = $#ARGV;
> my $file1 = $ARGV[$parameters - 1];
> my $file2 = $ARGV[$parameters];
> my $title1 = $ARGV[$parameters - 4];
> my $title2 = $ARGV[$parameters - 2];
> 
> my $title = "$title1  -   $title2";
> $title =~ s/\t/   /g;
> $title =~ s/ /\\ /g;
> my $command = qq($DIFF -c "set titlestring=$title" "$file1" "$file2");
> system qq($command);
> 
> 

Yes, that will suppress the whitespace outp

svn with linux: warning: no xauth data; using fake authentication data for X11 forwarding

[Leo Simon]

Hi

I'm using svn on a linux box, ubuntu hardy; the repository lives on a Sparc
workstation Sun-Fire-880.  I'm trying to set things up so that my coauthor can
check things into my repository.For some reason the usual svn_ssh command
doesn't work.   My coauthor is prompted for my password, but it's not
accepted.   Presumably this is a security setting on the Sparc.   So I've set
up a script so that when she svn's she first becomes me via an su command, and
then can then check in as I word.  This avoids the password problem as I have 
rsa
authentication set up.

This works but the problem is that it takes forever.   After a long period
of waiting, it says

Warning: No xauth data; using fake authentication data for X11 forwarding.

and then checks everything in as it is supposed to.

There's stuff on the web about this warning but it's all related to ssh.
Obviously I'm connecting with ssh_svn but the web suggestions don't seem 
to apply to my case.


Any help would be most appreciated!!

Leo

_____

Professor Leo Simonleosi...@berkeley.edu
Agricultural and Resource Economicshttp://are.berkeley.edu/~simon
207 Giannini Hall #3310(510) 917-2916  (cell)
University of California at Berkeley   (510) 642-8230  (office)
Berkeley CA 94720-3310 (510) 643-8911  (fax)

Crashes whilst importing from a repository dump

[Rowe, Simon]

Kind Regards,
Simon Rowe

Senior Manager Engineering
Siemens plc
Healthcare Sector
Molecular Imaging/MR Magnet Technology
Beaver House
23/38 Hythe Bridge Street
OXFORD OX1 2EP
United Kingdom
Direct Line +44 (0)1865 265566
Fax +44 (0)1865 265501
Mobile +44 (0) 7921243214

E-Mail simon.r...@siemens.com<mailto:simon.r...@siemens.com>
Siemens plc. Registered office: Faraday House, Sir William Siemens Square, 
Frimley,Camberley, GU16 8QD. Registered no: 727817, England.
This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the addressee. If you are not the 
addressee please note that any distribution, reproduction, copying, publication 
or use of this communication or the information is prohibited. If you have 
received this communication in error, please contact us immediately and also 
delete the communication from your computer.



SubversionCrashes.7z
Description: SubversionCrashes.7z

Systematic crash of client when running svn ls on a newly upgraded svnserver

[Simon Chalifoux]

Hello,

We recently migrated our SVN Server (Windows) (running the Slik SVN 
distribution) to version 1.10.4. Since that moment, whenever we try to run an 
"svn ls" on any part of the repo, our client crash (whatever client on 
Windows... CLI, TurtoiseSVN... CLI seems to work fine on Linux though). All the 
other operations seems to work fine. We try running an svnadmin upgrade on the 
repos but it didn't change anything. We are really in the dark right now. I've 
included a dump file and a crash log in case in can be of any use.

Anyone could shed even a tiny amount of light on this for us?

Thanks


Simon Chalifoux
Infrastructure manager - IT & Cloud
Office:  514.360.3686 x130
Mobile: 514.318.5154
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/Devolutions.png]<https://devolutions.net/?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/line.png]
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/spiceworks.png]<https://community.spiceworks.com/pages/devolutions?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/reddit.png]<https://www.reddit.com/r/Devolutions/?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/youtube.png]<https://www.youtube.com/user/Devolutions?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/twitter.png]<https://twitter.com/DevolutionsInc?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/linkedin.png]<https://www.linkedin.com/company/devolutions-inc-?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/facebook.png]<https://www.facebook.com/devolutionsinc?utm_source=Signature&utm_medium=email&utm_campaign=Signature>
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/Signature2018_09.png]
[http://webdevolutions.blob.core.windows.net/images/mail/signature/email/blog.png]<https://blog.devolutions.net/?utm_source=Signature&utm_medium=email&utm_campaign=Signature>




svn-crash-log20190904120206.dmp
Description: svn-crash-log20190904120206.dmp


svn-crash-log20190904120206.log
Description: svn-crash-log20190904120206.log

Lines duplicated in dest. file when merging back to trunk

[Saffer, Simon]

Hi,

I'm not subscribed on your mailing list so it would be great if you could Cc me 
in you responses.

I'm having problems with merges going wrong. In our company we sometimes put 
the same changes on several branches by hand (the reason for this involves code 
that has to talk to a legacy system with a very primitive VCS built in to the 
language itself).
But we also merge our branches using svn and we have discovered that our merges 
sometimes can go wrong. I have some short texts to illustrate what happens and 
also gives a repo-case:

We start out with a file that looks like this both on trunk and on our branch 
(A is first line in file and D is the last).

A
B
C
D

Note that there is a space character on the empty line between B and C.

Then we make a change on the trunk

A
B

   some change

C
D

And on our branch we make almost the same change

A
B
   some change

C
D

The only difference between the change on the trunk and on the branch is that 
the trunk has three space characters on the line between B and some change 
while the branch still only has one space character.
When merging the branch to the trun the result is the following:

A
B

   some change

   some change

C
D

We get no merge conflict, but the text is copied twice into the file on trunk.

I've been able to reproduce this with Collabnet, SlikSVN and Tortoise clients 
using version svn version 1.6.

Is this a known issue? Is it possible that it's already fixed in svn 1.7?

Best regards

Simon

RE: Lines duplicated in dest. file when merging back to trunk

[Saffer, Simon]

Hi,

I'm resending this email, now hopefully in plain text. Sorry about that.

I’m not subscribed on your mailing list so it would be great if you could Cc me 
in your responses.

I’m having problems with merges going wrong. In our company we sometimes put 
the same changes on several branches by hand (the reason for this involves code 
that has to talk to a legacy system with a very primitive VCS built in to the 
language itself).
But we also merge our branches using svn and we have discovered that our merges 
sometimes can go wrong. I have some short texts to illustrate what happens and 
also gives a repo-case:

We start out with a file that looks like this both on trunk and on our branch 
(A is first line in file and D is the last).

A
B

C
D

Note that there is a space character on the empty line between B and C.

Then we make a change on the trunk

A
B
   
   some change
   
C
D

And on our branch we make almost the same change

A
B
 
   some change
   
C
D

The only difference between the change on the trunk and on the branch is that 
the trunk has three space characters on the line between B and some change 
while the branch still only has one space character.
When merging the branch to the trunk the result is the following:

A
B
   
   some change
   
   some change
   
C
D

We get no merge conflict, but the text is copied twice into the file on trunk.

I’ve been able to reproduce this with Collabnet, SlikSVN and Tortoise clients 
using version svn version 1.6.

Is this a known issue? Is it possible that it’s already fixed in svn 1.7?

Best regards

Simon

Error parsing config file

[Simon Large]

Hi guys,

I've seen this error reported twice on the TSVN mailing list and can
now reproduce it. The symptom is and error message on all subversion
operations:

Error while parsing config file: BlahBlah\config:
line 109: Option expected

It seems that if there is any leading space before the option name,
this error is thrown. I tested with Windows and Unix line endings and
the result was the same. Although it is easy to fix, it seem
unnecessarily restrictive to require no white-space before option
names, when any or no white-space is permitted elsewhere in the line.


Simon

Username in Repository URL with Serf/ra_serf

[Simon Wilson]

Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that contain 
usernames to svn, i.e.

  svn --username user ls https://server.com/repos/project/

works fine but

  svn ls https://u...@server.com/repos/project/

results in errors. The same URL worked fine with Neon in 1.7 and older. The 
exact errors depend on the server I am contacting and the protocol used (HTTP 
or HTTPS).

For example, with a repository hosted with Beanstalk (www.beanstalkapp.com)

  svn ls https://u...@domain.svn.beanstalkapp.com/repos

I get the following errors:

  svn: E175002: Unable to connect to a repository at URL 
'https://u...@domain.svn.beanstalkapp.com/repos'
  svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/repos'
  svn: E175002: Additional errors:
  svn: E175002: OPTIONS request on '/repos' failed: 500 Internal Server Error

Attempting a similar request with CloudForge:

  svn ls https://u...@domain.svn.cloudforge.com/repos

I get the following errors:

  svn: E175002: Unexpected HTTP status 405 'Method Not Allowed' on '/repos'
  svn: E175002: Additional errors:
  svn: E175002: PROPFIND request on '/repos' failed: 405 Method Not Allowed

In both cases the request works as expected when the user is removed from the 
URL.

I have been able to successfully connect to an internal test server via HTTP 
with basic authentication but attempting the same request via HTTPS with client 
certificate-based authentication results in the following errors:

  svn: E175002: Unable to connect to a repository at URL 
'https://user@192.168.4.240/repos'
  svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/repos'

These errors are output *after* the client certificate path and passphrase 
prompts.

The fact that 1.7/Neon supported such URLs indicates that this is a significant 
regression in 1.8. Can anyone throw any light on the cause of these errors? Is 
this a known issue with Serf/ra_serf?

Some additional info:

- This behavior is not specific to svn 1.8: 1.7.10 generates the same errors 
when ra_serf is enabled.
- This behavior is specific to Serf. I do not get the same errors with 
Neon/ra_neon in 1.4, 1.5, 1.6 or 1.7.
- All tests were done on Mac OS X 10.8.
- 1.8 behavior was tested using a) 1.8.1 binaries we built from source and b) 
1.8.1 binaries downloaded from WANdisco. I don't believe that this behavior is 
specific to our svn build.
- 1.7 behavior was tested using 1.7.10 binaries built and distributed by Apple 
with Xcode 5.
- I have tested a build of 1.8.1 with Serf 1.3.1 but experience the same errors.

Many thanks,
Simon

svn commit of locked/unmodified files

[Simon Butler]

hi

when i lock multiple files in a directory modify only one and then commit
the directory ,the last changed rev on all files is set to the commit
revision. however, when i query the server the repository last changed rev
is unchanged.

why does the svn workspace get a different answer for "last changed rev"
than the svn server?

here's a quick shell script showing the problem.

thanks in advance for any insight on this.



#!/bin/bash
cd /tmp
mkdir svntest
cd !$
svnadmin create repo
svn mkdir file:///tmp/svntest/repo/foo -m test
svn co file:///tmp/svntest/repo/foo foo
cd foo
touch a b
svn add a b
svn commit -m bar
svn lock a b
echo a > a
svn commit -m barf
svn st -v
svn info b
svn info file:///tmp/svntest/repo/foo/b
cd ..
svn co file:///tmp/svntest/repo/foo too
svn st -v foo too