RE: Something like svn:executable for the read-only bit?
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Thursday, 16 July 2015 10:53 AM To: users@subversion.apache.org Subject: Re: Something like svn:executable for the read-only bit? On 16.07.2015 02:41, Evan Driscoll wrote: We have some generated files that, for logistical reasons, are way easier to just check into the respository alongside the source than to build on-demand. (They're small text files, not some big binary or something like that.) Is there a way to instruct Subversion to remove write access when checking them out? Obviously the user could just chmod them to add it back, but the point is just to avoid someone unintentionally modifying the generated file instead of the source, not to keep people from being jerks. :-) Setting the svn:needs-lock property will make files in the working copy read-only. Hi Evan, You can even do this automatically from the client settings or the server (from 1.5). If you look at the SVN book (http://svnbook.red-bean.com/) under Chapter 3: Advanced Topics - Properties - Automatic Property Setting, it talks about MIME types. It says that SVN will automatically set the svn:executable property on newly added or imported files whose execute bit is enabled. By enabling auto-props and including a MIME type statement similar to the following in your config file, you can automatically set the read-only properties: In our Windows world, we use a registry tool to set it on the client. Here are the relevant bits of our .reg file: ... [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany] enable-auto-props=yes ... [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props] ... *.exe=svn:needs-lock ... Obviously, this would need to be updated for your Unix system, but that's what we're doing here. The SVN book should give you good guidance there. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: fsfs storage
From: NS Klanten Sent: Monday, 11 May 2015 6:20 AM Subject: fsfs storage Hello all, Where are the initial or base text files (source codes) are stored in fsfs storage ? I commit a new source code to my svn server, however after searching all the related svn folders in my server, I can not find the plain text file. I assume that source code is just stored as plain text in fsfs storage and it isn't hashed, is my assumption correct? Thanks in advance for your help, Jennifer Brooks. Hi Jennifer, The files are stored in original format in your working copy under ./.svn/pristine/*, but with hashed names. On the server, they're stored under ./db/revs as a series of deltas. If you look at ./db/revs/0 with a text editor, for example, you'll see it starts with the word PLAIN. Every other file from there on starts with the word DELTA. For the sake of efficient storage, there is no plain storage of the original files. You'll find this with many version control systems. If you're only storing text files, there's half a chance of understanding what's stored in the delta files. I wouldn't even consider editing them, though. There is probably a setting somewhere to allow a shadow version to be set up somewhere - if not, it would be a nice idea. I know in SourceSafe, I was able to set up shadow folders on a server so that changes were automatically updated. I suspect that SubVersion would require a server-side post-commit hook to be written to do the same job. Does anybody have one they could share? Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Trying to restore a corrupted repo
[snip] First step is to *write lock* the old repository, to avoid accumulating history on broken history. Absolutely - and make sure the lock stays locked forever more. You will be *breaking history* due to the corrupted repo. You should ideally create a new repo to do the repairs in, explain the situation,and tell your user community to set aside their working copies and make clean checkouts when you're done. The old repo should be locked, and the new repo should have a new name to avoid any confusion. What I've done in the past is to: a) Write-lock the old repository; b) Create and populate a new repository by whatever means are required; c) Ensure nobody is trying to access either repository for the next few steps (pause Apache, or whatever); d) Re-name the OLD repository to reflect its broken/BDB/whatever status; e) Rename the NEW repository to the old name; and, finally: f) Re-enable access to the repositories. I even created a batch file to do this when we upgraded SVN recently and could no longer access the BDB repositories. This is one of the difficulties with the absolute central repository approach of Subversion and its spiritual ancestor, CVS. If anything happens to the central repository, you have to re-establish the effectively server/client relationship correctly or be at risk of corrupting your history, *again*. This is why your servers should have an effective backup and restoration system. Ours uses a SAN with off-site backup. Then, if we catch the corruption early enough we've only lost a day's history. It can happen with more distributed systems as well, it's just more likely when one particular repository is considered canonical in your particular workflow. If the history is replaced or corrupted behind your back, you can be in real trouble. I think this is true of any single-site storage system - electronic or otherwise. If there's a single point of failure, and you rely on the information/items, there's potential for (business) disaster. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: svn command line client 1.8.8 - Error: file name or extension is too long
On Mon, Sep 15, 2014 at 09:38:29AM +1000, Geoff Field wrote: However, please note that Milan finally mannaged to commit all the files by doing them in smaller batches. That would seem to indicate some other issue. What were the commands he typed which worked? Sorry Stefan, but I'm the wrong person to ask about this. However, from Milan's original post: Then I tried to commit changes in chunks (I did not change any path or file name), which finally worked. I had 285 files to commit. Note that he also said: This file in its path is far away from the longest name in project... This implies that files with longer pathnames successfully committed. However, it's up to Milan to confirm or deny this. There are references to absolute paths working around the problem in the archives: http://svn.haxx.se/users/archive-2005-02/1088.shtml There are also posts that seem to contradict this theory: http://svn.haxx.se/dev/archive-2004-10/1482.shtml I don't use windows so I can't verify any of this myself. Part of the problem is that the rules very much depend on which version of Windows is being used. Back in 2004/2005, XP was the bees' knees. (Mind you, I'm typing this on a machine that's still running XP.) Nowadays, things are somewhat different. The next OS produced by MS was a 64-bit one, with all sorts of rule (and, of course, API) changes. It would help if Milan told us more details, such as the exact platform (which Windows?) and the exact commands entered. We know the SVN version from this: C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: svn command line client 1.8.8 - Error: file name or extension is too long
On Fri, Sep 12, 2014 at 11:29:37AM +0200, milan_plan...@swissre.com wrote: Dear team, I tried to commit my changes with following error message: Error:Cannot run program C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe (in directory C:\Users\S3F96Q\work\sources\g10ct\SR_G10_CT\modules\sr-g10-c t-batch-xd\src\main\resources): CreateProcess error=206, The filename or extension is too long This file in its path is far away from the longest name in project and I only changed the content of its file (did not changed the path or file name). This error prevents me to commit my changes. I also tried to checkout it from scratch, so that path changed to: C:\work\sources\g10ct\SR_G10_CT\modules\sr-g10-ct-batch-xd\src\main\re sources, but id did not help. Then I tried to commit changes in chunks (I did not change any path or file name), which finally worked. I had 285 files to commit. 1. Is it bug? At least message does not correspond to real error 2. Can it be configurable (the max file count to commit or some buffer)? (How?) 3. Is it fixed in some newer version? Thank you With regards Milan Plancik IIRC this is a limitation of windows. Yes, there is such a limitation of Windows. I've encountered it before in other applications. There's a known issue with paths over 260 characters long, INCLUDING the drive letter, the colon AND the terminating NUL. See this MSDN article: http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath If you prepend the string '\\?\' to the path, it's meant to allow 32,767 Unicode characters of path name. We've found, however, that some languages (such as National Instruments' LabVIEW up to version 8.6 at least) don't allow this. There are two approaches available in this case: 1) Shorten your path names. 2) Use the DOS subst command to create a new virtual drive starting at an appropriate place in the tree (preferably the directory where the .svn directory resides). It would be something like SUBST Z: C:\work\sources\g10ct When you're done, you can then do SUBST Z: /D to delete it. However, please note that Milan finally mannaged to commit all the files by doing them in smaller batches. That would seem to indicate some other issue. Passing absolute paths on the command line should work around it. Probably not, given what I've just discussed. BTW, please try to avoid posting disclaimers like the one below to public mailing list. See http://producingoss.com/en/communications.html#face Some of us are subject to the whims and caprices of a corporate IT department (and their bosses). I know I am. We can't avoid the disclaimers if we're using our work emails. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE:
Does this user actually post anything useful, or is it a spammer who should be removed from the list? From: Jacky wong [mailto:wjacky...@gmail.com] Sent: Monday, 21 July 2014 14:12 PM To: users@subversion.apache.org Subject: -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Moving a repository with svn:externals using absolute paths (URLs)
From: Nico Kadel-Garcia On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas nicolas.bris...@airbus.commailto:nicolas.bris...@airbus.com wrote: Hi, We've been using svn successfully for years on a server, and now have to migrate to a new one. We are hit by the known issue of svn:externals containing absolute paths to the repo to be moved, since we started with versions 1.5 without support for relative URLs. We've been researching how to properly do this, knowing that we handle certified SW on that server, so losing data or corrupting the repo is not allowed, and we want to be able to go back in time and checkout an old state at any time. We've experimented the svndumptool (http://svn.borg.ch/svndumptool/) referenced for instance in this post: http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository It seems to be the only tool doing what we want, and it apparently works, but before doing the change on the production repo we'd like to know what experiences there are with this tool, and if it's safe to use - or if there is a better alternative. Thanks for your feedback if you have any experience with this, Nicolas Hi Nicolas, We upgraded from 1.2 to 1.8 in one fell swoop. We don't use externals, which made things easier. However, most of our 1.2 repositories were in BDB format, which off-the-shelf Windows binaries of 1.8 don't handle. (I am somewhat averse to trying to recompile for Windows, as that would entail finding and setting up the correct compilation environment for it - too much like work.) I wrote a batch file to do a dump, reload and rename on each repository. Basically, the old repositories were left in place, but with the name changed to append _BDB and the re-loaded repositories in FSFS format run live. Full history now lives in both sets of repositories, with the BDB versions retained in case we ever need to go back and double-check. The simple answer I'd recommend is don't. The amount of time you are going to spend trying to cross migrate old build environments is expensive, fragile, and requires polluting your history to generate a new, and misleading one, pointing to the correct SVN server. Set aside the legacy configuration, incompatible as it is with modern relative URL's, for reference and log analysis only. Keep it pristine, and don't muck with the history. Bring only the relevant components to your new server, on a scheduled cutover date, and take the opportunity to discard bulky binaries and branches and logs and security sensitive debris with the move to a new server with a new URL. Drop a README.txt in place on the new server pointing to the old, legacy repository, and kick it aside. This is basically what we did, but without mucking about to edit dump files, etc. As Nico says, keep the originals pristine. Disk space is cheap (although backup on alternative storage might not be). If your employers or clients cannot accept this, create migration branches, and tags as soon as you do the replication, with the safe new svn:externals settings. This is much safer than manipulating the old logs: once you get into manipulating logs, it's like cross-breeding puppies from the same litter: you may get the champion you want, but the practice can also lead to a lot disasters which will be blamed on the editing, even if it's not really the source of the problem. There's also the point that any editing you do is (a) prone to human error and (b) likely to consume large amounts of your time. In our duplication effort, we also set all the permissions on the old repositories to read-only, to limit the chances of cross-contamination. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Moving a repository with svn:externals using absolute paths (URLs)
From: Nico Kadel-Garcia On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote: In our duplication effort, we also set all the permissions on the old repositories to read-only, to limit the chances of cross-contamination. Just to be clear, I'm not talking about the FILE permissions here, merely the SVN access permissions. To be really clear, the original repositories are only being kept as a paranoia measure, just in case our customers (or legal representatives) require unsullied history at some indefinite time in the future. Regards, Geoff This. So much this. When people want to keep, and keep cross-merging, the contents of multiple distinct live repositories while work is being replicated and cross-merged from all of them, it's usually time to look for a new job: The vast majority of those repositories have been unused for some years, and our development team is (now) small enough so that I can guarantee there was no work proceeding on any of them. Naturally, I also shut down SubVersion while it was in progress, just in case. someone has been excited by the shiny tools and forgotten Ooh, shiny ... What were we talking about? ;-) source control is a 24x7, it must *work* and work *every time* resource. Quite right. That's why our repositories are on a RAID system (now a SAN, actually) with regular backup (including off-site). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN Query about granting access
From: karthik kg Sent: Wednesday, 9 April 2014 13:17 PM Hi Geoff, Apologies for replying to you. Please find my comments fro your queries below. Replying directly to me is not a problem, really. What might be a problem is that I don't know as many of the answers as some of the other contributors to this mailing list. What result/message is the user actually seeing? I'm facing No ERROR at the moment. Fair enough. From the description, that's what I'd expect. From what I'm seeing, you're trying to give that specific user read-only access, but they're getting read/write access. Yes, That's right. Even post changing the user settings, i m getting read-write access for that user(d389678) Some of my following queries are based on Windows and might not apply on your platform: Oh, anyway my platform is LINUX I thought it might have been, but it's worth being sure. What specific version? Have they actually logged out and in again? Yes, Tried Have you restarted the httpd daemon after reconfiguring? (This shouldn't be necessary, but it could be worth a try.) Yes Tried. Do you grant global read/write access to that repository at all? Not sure, about this. Can you please tell me where this param value specified? In your Subversion.conf file, there could be a line - most likely related to that repository - that says something like: * = rw Alternatively, you could have something like this to control global access: [/] * = rw If there's a line like that in there, it's possible it will override the individual user settings. To make it global read-only, simply change it to: * = r Of course, I'm making a lot of assumptions here, but that's what works for us. We've been known to make specific repositories private in our configuration by saying (for that repository): * = I'm not totally convinced it will work, since the individual settings seem to override the global ones. More knowledgeable heads than mine might have more of a clue. Having said all this, one has to ask if restricting that user's access is strictly necessary. Given that SVN logs all writes and changes and that everything can be reversed, is it really such a huge risk? On the other hand, of course, there's the learning exercise for working out how to set the configuration file up. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN Query about granting access
From: Daniel Shahaf
Sent: Monday, 7 April 2014 18:13 PM
karthik kg wrote on Mon, Apr 07, 2014 at 17:40:54 +1000:
Repository name - TTN
Location on the server -
/apps/bss/SubVersion_Repository/TTN
I tired editing the
/var/opt/app/SubVersion_Repository/NTT/conf/auth
file with below parameter for providing read only access to
the TTN repository.
[repository:/NTT]
d389678 = 'r'
As well as what Daniel has quite rightly said, it looks like there's a space at
the start of the line. I seem to remember another message on this list
commenting that spaces at the start of the line might not be a good idea.
Also, Daniel doesn't say it, but the repository name doesn't look right.
Daniel's edited version should get your user authenticated correctly.
But even after changing the auth file, i can see i hav
write access to
the user d389678.
My query is, is there any file that needs to be updated? if yes,
kindly provide us the detailed view of the parameter that
needs to be
updated on the file.
There isn't any other file, but you didn't edit that file correctly.
Don't use single quotes (') in the value. It is not
guaranteed to work and may stop working in future versions.
I think you mean:
[TTN:/]
d389678 = r
That is: the / path within the repository called TTN.
If this doesn't work, please indicate whether you use
svnserve or httpd, and whether you use -r/--root (svnserve)
or SVNParentPath (httpd) and if so what path it is set to.
Good luck,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files.
RE: SVN Query about granting access
Hi Karthik,
Please ensure you reply to the whole group, as there are many people on the
mailing list who are far more knowledgeable than I. Also, the convention seems
to be to use plain-text and to reply within/under the quoted text.
From: karthik kg
Sent: Tuesday, 8 April 2014 15:11 PM
To: Geoff Field
Subject: Re: SVN Query about granting access
Hi Geoff,
Thanks for the information. But still it didnt work out.
What result/message is the user actually seeing?
From what I'm seeing, you're trying to give that specific user read-only
access, but they're getting read/write access.
Some of my following queries are based on Windows and might not apply on your
platform:
Have they actually logged out and in again?
Have you restarted the httpd daemon after reconfiguring? (This shouldn't be
necessary, but it could be worth a try.)
Do you grant global read/write access to that repository at all?
My repository uses httpd and the SVN path in Subversion.conf is
SVNPath /var/opt/app/photon/repository/NTT
That's a start. Daniel also asked for: whether you use -r/--root (svnserve)
or SVNParentPath (httpd) and if so what path it is set to.
Those more knowledgeable about using httpd on a *nix platform (I'm using
Windows at present) will probably be looking for a more complete extract from
the Subversion.conf file about now.
Regards,
Geoff
On Tue, Apr 8, 2014 at 9:03 AM, Geoff Field geoff_fi...@aapl.com.au
wrote:
From: Daniel Shahaf
Sent: Monday, 7 April 2014 18:13 PM
karthik kg wrote on Mon, Apr 07, 2014 at 17:40:54 +1000:
Repository name - TTN
Location on the server -
/apps/bss/SubVersion_Repository/TTN
I tired editing the
/var/opt/app/SubVersion_Repository/NTT/conf/auth
file with below parameter for providing read only access to
the TTN repository.
[repository:/NTT]
d389678 = 'r'
As well as what Daniel has quite rightly said, it looks like
there's a space at the start of the line. I seem to remember another message
on this list commenting that spaces at the start of the line might not be a
good idea.
Also, Daniel doesn't say it, but the repository name doesn't
look right. Daniel's edited version should get your user authenticated
correctly.
But even after changing the auth file, i can see i hav
write access to
the user d389678.
My query is, is there any file that needs to be updated? if
yes,
kindly provide us the detailed view of the parameter that
needs to be
updated on the file.
There isn't any other file, but you didn't edit that file
correctly.
Don't use single quotes (') in the value. It is not
guaranteed to work and may stop working in future versions.
I think you mean:
[TTN:/]
d389678 = r
That is: the / path within the repository called TTN.
If this doesn't work, please indicate whether you use
svnserve or httpd, and whether you use -r/--root (svnserve)
or SVNParentPath (httpd) and if so what path it is set to.
Good luck,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
SVN Development Tracking Methodologies and Tools
This is a question for the SubVersion developers. What tools and/or methods did you use for tracking the various tasks for developing SubVersion? Was it just a bunch of emails, or did you use an issue tracker (or similar) for tasks? If you've been involved in other open-source developments, how were they done from a project management perspective? Just out of interest. Thanks for any feedback. Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Upgrade SVN from version 1.5.6 (r36142) to 1.8.5
Hi Guido, -Original Message- From: Stefan Sperling Sent: Friday, 14 February 2014 1:03 AM On Thu, Feb 13, 2014 at 10:57:15AM -0200, Guido Larrain wrote: Hello; I'm planning to upgrade my SVN from version 1.5.6 (r36142) to 1.8.5 and i wanna know if i need to do some special steps to perform this. Is that the client or the server? If it's the client, you should have no problems. The only potential problem will be if you have working copies on a shared drive (it's not recommended, but it happens) and other people who access these are using different versions. If it's the server, you might need to upgrade any BDB repositories to FSFS. Regardless, read the notes on the links that Stefan provided. Thanks in advance!! -- Guido The most special step (most people don't seem to do this ;) is to read the upgrade documentation in the release notes for each intermediate release (1.6 to 1.8 in your case), which document the special steps, if any, better than any subscriber of this list could recite from memory. http://subversion.apache.org/docs/release-notes/1.6.html#compatibility http://subversion.apache.org/docs/release-notes/1.7.html#compatibility http://subversion.apache.org/docs/release-notes/1.8.html#compatibility If you still have questions after reading, feel free to ask. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How to prevent casual browsing
Hi Peter From: Peter Flynn Sent: Monday, 2 December 2013 1:40 AM I have a number of svn repositories running under Apache+subversion on CentOS6/64, with Submin to provide a web GUI to manage them: server.name/svn/foo server.name/svn/bar server.name/svn/blort etc All of them are private; all but one of them are single-user (me) so that I can carry on working from any of my machines in multiple locations. One of them is shared with colleagues on a project: they all have read/write privs on that repo. Are they separate projects or separate accesses to the same project? You know, of course, that you can set up authz privileges to specific subdirectories? The URIs are not published or linked, and my colleagues are all well aware of the need to keep their shared URI private. But the requirement is that none of them must be open to casual read access via a web browser, in case someone happen to stumble upon or guess the URI. I am having problems getting the access privs right, as they keep causing svn: E22: Not authorized to open root of edit operation during an svn up. However, in a long exchange with the very helpful submin support (https://ssl.supermind.nl/collab/projects/submin/ticket/336) we have failed to identify settings that work. Not sure about this one. Currently the svn/conf/authz file says [groups] dev = a,b,c,d,e,me [foo:/] @dev = rw [bar:/] For the private one, try adding the following line here: * = That turns off read and write access for everybody EXCEPT the explicitly-named members. At least, it works that way for us. me = rw [blort:/] me = rw The Apache conf.d/subversion.conf says: Location /svn DAV svn SVNParentPath /var/lib/submin/svn # removed GET from LimitExcept to prevent casual browsing LimitExcept PROPFIND OPTIONS REPORT AuthType Basic AuthName Authorization Realm AuthUserFile /etc/svn.auth Require valid-user /LimitExcept /Location and svn.auth specifies a username:encryptedpassword pair for each member of [groups] in the usual way. 1. Browsing with a web browser causes a prompt for the username/password as expected. 2. An svn ci operation works fine. 3. An svn up operation fails, and always causes an E22 error. 4. Replacing the GET in the LimitExcept config allows svn up to work without error, but allows casual browsing of the web interface. Is there a way to prevent the casual browsing while avoiding the E22 error? -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Method not allowed exception
Sorry for top-posting, but although Brane is right, he's not being as helpful as he could. Stefano, I had pretty much the same issue. A workaround is to only do actions (other than Commit) on unlocked working copies. That is, before doing a copy (in particular), make sure all locks are released. The fix that worked for me was to update the server. I downloaded the Wandisco server binaries (which are patched with the fix to this issue) and then copied mod_dav*.so to the modules directory of the Apache installation that we have actually working. (Ideally, I'd just install and run the Wandisco binaries, but with our configuration it was easiest to get working by just doing the copy.) Regards, Geoff From: Branko Čibej Sent: Friday, 15 November 2013 18:09 PM To: users@subversion.apache.org Subject: Re: Method not allowed exception On 15.11.2013 07:47, Stefano Fraccaro wrote: Il 14/11/2013 22:35, Ben Reser ha scritto: Can you elaborate what method you're seeing method not allowed with? Or if you were running a svn client what command you were running? TortoiseSVN SVN Checkout The one case where we made such a change that comes to mind is with LOCK. LOCK per the RFC can lock files that don't exist (otherwise known as an unmapped url or null resources). http://webdav.org/specs/rfc4918.html#lock-unmapped-urls http://webdav.org/specs/rfc2518.html#rfc.section.7.4 We only support this when SVNAutoversioning is turned on and return a method not allowed error if this isn't turned on. We felt that the method not allowed error was the logical error to return. The other cases where we return method not allowed typically are cases where we don't allow that method on regular URLs unless auto-versioning is enabled. We have an apache installation with subversion modules ( http://webserver/ ). All our repositories are in svn subfolder ( http://webserver/svn/RepositoryName ) If I checkout the url 'http://webserver/badname/RepositoryName', subversion return '405 Method not allowed' instead of '404 Url not found'. Unexpected HTTP status 405 Method Not Allowed on '/badname/RepositoryName' Additional errors: PROPFIND request on '/badname/RepositoryName' failed: 405 Method not allowed I think you are mistaken, this error probably not returned by Subversion (since it's not configured on that location) but by the Apache HTTPd server itself. Most likely your server interprets the request as a PROPFIND on directory badname within the directory defined by the server configuration option DocumentRoot. The default server configuration probably only allows GET requests on such paths; which makes a kind of sense, since the PROPFIND method is defined by the DAV protocol, not HTTP itself. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: NOW RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
From: Ben Reser Sent: Saturday, 9 November 2013 4:30 AM On 11/7/13 9:55 PM, Ben Reser wrote: Putting my own corporate hat on for a moment here. WANdisco binaries that come with httpd should be patched as well. I need to ask the individual that builds them to verify for sure. If you find that they are not let me know and I'll see that this changes. You can find the WANdisco binaries here for free download: http://www.wandisco.com/subversion/download I have confirmed that the WANDisco binaries for Windows and Solaris include httpd and have been patched. Other platforms do not include Apache httpd but use the one already on the host OS/distribution. Hi All, After installing several different versions and fiddling around with various options in the configuration files, I ended up just copying the mod_dav*.so from the WANDisco modules directory to the working Apache directory. Everything now seems to work fine. Copying locked directory trees is now transparent. Thanks very much to Ben (and all the many others who responded). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
Sorry to dredge up an old thread, but this issue is NOT really resolved properly. (Also, I noticed a post that said that this would be treated more seriously if it was brought up again without the RESOLVED tag.) There's a known issue with the Apache server software (https://issues.apache.org/bugzilla/show_bug.cgi?id=55306) whereby if the directory tree being copied has a lock anywhere in it, the DAV component will send a 424 error. Why a copy should need to be concerned about a lock is a mystery. The so-called Resolution listed in the mailing lists here was simply to break or release the locks. It's not really a fix, just a workaround. The most recent release of Apache is 2.4.6 from July, but the last activity in the bug report is from October. Any idea when the next release is due? The Apache release policy (http://www.apache.org/dev/release.html) doesn't seem to tell me anything significant about that. (I do realise it's an open source project and therefore dependant on people volunteering their time.) In the meantime, we will all have to continue trying to remember to unlock files before attempting a branch, tag, or other copy. Either that, or revert to an earlier version of Apache. From: Brenden Walker Sent: Thursday, 8 August 2013 6:08 AM From: Bob Archer Sent: Wednesday, August 07, 2013 2:30 PM Brenden Walker writes: svn: E175002: Adding directory failed: COPY on /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed Dependency) Turned out that another developer had locks on several files. Confirmed that was the problem. A more specific error message would have been handy here. The error message was reasonably specific, but it actually points at another bug. Can you describe how to reproduce the problem? What sort of locks prevent a COPY? Orphaned locks perhaps? They were working copy locks from another developer. I asked him to try the build himself to see if it allows the user who holds the lock to svn copy, haven't heard back from that. ANY lock seems to work. I was able to reproduce the issue by locking the files myself (and to correct it by unlocking the files. Breaking the locks allowed me to do an SVN copy. I haven't tried reproducing, but I certainly can if that would be helpful. Are you sharing working copies with multiple people? If by that you mean checking out somewhere and having multiple people using the same working copy, no. Each developer has their own working copy. The reason the files were locked is that they're unmergeable binaries, AND most people here are still used to StarTeam. I offered up some other options to keep other developers from accidentally changing these files. We, too, have unmergeable binaries, so we use autoprops - including needs lock properties as appropriate. This applies for even one-person teams (our current default). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
From: Mark Phippard Sent: Friday, 8 November 2013 11:47 AM If it helps, the Subversion server binaries we provide at CollabNet have applied the patch that fixed this to Apache 2.4.6. Thanks Mark, I'm downloading and installing now, but I'll have to fiddle around with our multiple server versions to get it to actually work now. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
From: Ben Reser Sent: Friday, 8 November 2013 11:55 AM On 11/7/13 4:31 PM, Geoff Field wrote: Sorry to dredge up an old thread, but this issue is NOT really resolved properly. (Also, I noticed a post that said that this would be treated more seriously if it was brought up again without the RESOLVED tag.) Not sure what you mean by this. The issue has been taken seriously, it's just that Apache httpd doesn't release very often. Sorry, I sometimes fail to word things correctly. (As a native - and monolingual - English speaker, there's little excuse for that.) I meant that in my research, I saw a post by a developer (somewhere - I no longer have a link) that referred to this thread (and a couple of others, I think) but said words to the effect of unfortunately, all the threads mention that they're RESOLVED so it's not receiving much attention. If somebody can post again, we can raise the priority. I'm just trying to bump the priority again, given our circumstances. Specifically, the server is a Windows Server 2003 system that's mostly under the control of a separate department to my own. It was originally set up for SVN by people who are no longer here and I'm learning as I go. There is an installation of Cygwin on the machine, but no gcc (nor any other development systems). The C: drive (where the programs reside) doesn't have a lot of spare space (but I can always drop things on the RAID drive L: where the repositories reside). There's a known issue with the Apache server software (https://issues.apache.org/bugzilla/show_bug.cgi?id=55306) whereby if the directory tree being copied has a lock anywhere in it, the DAV component will send a 424 error. Why a copy should need to be concerned about a lock is a mystery. The existing mod_dav module didn't properly comply with the RFC for DAV that specifies that COPY methods should enforce If: headers in the request. So is it just mod_dav*.so that's affected? Someone decided to fix this, but in the process they proceed to enforce some additional restrictions (specifically that the source and the parent of the source are checked for write access). In 2.2.25 and 2.4.6 we fixed the requirement of the parent, but missed the issue with the lock on the source itself. Sadly we found the second issue shortly after the releases and now we're waiting for another release cycle to get it in your hands on a release. I look forward to release day, but I'll try not to pester people too much about it. The so-called Resolution listed in the mailing lists here was simply to break or release the locks. It's not really a fix, just a workaround. No I'd say the resolution is to apply the patch that has been written to your httpd. I agree. Breaking/releasing locks is NOT a resolution. Applying patches (or patched software) is. Is there an easy way to apply a patch on a Windows server with limited drive space for extra tools such as compilers? The most recent release of Apache is 2.4.6 from July, but the last activity in the bug report is from October. Any idea when the next release is due? The Apache release policy (http://www.apache.org/dev/release.html) doesn't seem to tell me anything significant about that. (I do realise it's an open source project and therefore dependant on people volunteering their time.) I don't know for sure but there was some desire to do a httpd 2.4.x release in October. For other reasons unrelated to this it hasn't happened. You don't mean to say you actually have *lives*?? ;-) I see what I can do to nudge things along. Unfortunately, as a fairly new httpd committer, I'm not sure how to do the releases myself yet. Learning curves are fun, aren't they? In the meantime, we will all have to continue trying to remember to unlock files before attempting a branch, tag, or other copy. Either that, or revert to an earlier version of Apache. My suggestion would be to apply the patch to your local httpd. I'd meant to post some copy of the patches here on the list to help with this for the various mod_dav issues that are floating around out there and had forgotten to do it. I'll be sure to make a users post with these details here shortly. Thanks. I could probably find the patch (or a patch) with a little more Googling. Applying it is a different story. As I said above, I don't have complete control of the server. Changing the OS would take some finagling. But for your immediate consumption for this specific issue. The following patches will work against the respective httpd versions: https://people.apache.org/~breser/httpd/2.2.x/patches/pr55306.patch https://people.apache.org/~breser/httpd/2.4.x/patches/pr55306.patch And now I don't even have to Google. Hope this helps you. Thanks. It was very helpful and informative. Regards, Geoff -- Apologies for the auto-generated legal boilerplate
RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
From: Ben Reser Sent: Friday, 8 November 2013 16:55 PM On 11/7/13 6:37 PM, Geoff Field wrote: I'm just trying to bump the priority again, given our circumstances. Consider it bumped. :) Thanks Ben. I noticed your post on the matter. So is it just mod_dav*.so that's affected? Correct, this is only applicable to DAV. You won't see this problem if you're using svnserve and it doesn't impact things that aren't DAV related with respect to httpd. In practice this makes it generally specific to Subversion. Understood. In our case, SVN is the entire reason we have Apache running at all. Our IT Department really favours the MS solution. Though I'm sure there's some people out there using mod_dav_fs (presumably those people are the ones that wanted the fix that triggered several problems for us). I agree. Breaking/releasing locks is NOT a resolution. Applying patches (or patched software) is. Is there an easy way to apply a patch on a Windows server with limited drive space for extra tools such as compilers? Building httpd on Windows is unfortunately not easy at this time. I suspected as much. Oh well. I'd suggest going with a binary produced by one of the vendors. I think several have already patched. Mark mentioned that Collab.Net's packages are patched. I've downloaded those, too, but the installation hasn't taken yet. I'll have to edit the httpd.conf a bit more carefully to make things work with it. (At present, I'm getting an error 1, which I'm sure is due to a misconfiguration. I'll RTFM before posting any more about that. Quite likely, I should have tried the vanilla install first, then modified to suit.) Maybe one of the other providers will chime in here that there's are patched as well. Putting my own corporate hat on for a moment here. WANdisco binaries that come with httpd should be patched as well. I need to ask the individual that builds them to verify for sure. If you find that they are not let me know and I'll see that this changes. You can find the WANdisco binaries here for free download: http://www.wandisco.com/subversion/download Thanks. I've downloaded the WanDisco version and I'll try the installation on Monday. (It's past home time on a Friday here in South-Eastern Australia.) If the WanDisco binary works better for me, I will probably not do any more work on the Collabnet update. Either way, I'll let you know. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: how to unsubscribe
Hi there, You need to send an email to users-unsubscr...@subversion.apache.orgmailto:users-unsubscr...@subversion.apache.org?subject=unsubscribe to unsubscribe from this list. Regards, Geoff -- Geoff Field Testing Coordinator, Work Health Safety Rep, Chief Fire Warden, First Aider Australian Arrow Pty Ltd www.australianarrow.com.au 46 Lathams Rd, Carrum Downs, Vic, 3201, Australia phone (+61-3) 97850597, fax (+61-3) 9785 0583 GYNET x-067-597 From: chenc...@gmail.com [mailto:chenc...@gmail.com] Sent: Sunday, 20 October 2013 16:02 PM To: users@subversion.apache.org Subject: how to unsubscribe how to unsubscribe ? chenc...@gmail.com From: Ivan Zhakovmailto:i...@visualsvn.com Date: 2013-10-18 22:22 To: Karol Szkudlarekmailto:ka...@mikronika.com.pl CC: branemailto:br...@wandisco.com; Bob Archermailto:bob.arc...@amsi.com; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: Re: svn 1.8.3 on windows often crashes On 18 October 2013 18:06, Karol Szkudlarek ka...@mikronika.com.pl wrote: I'm asked about: OK. So please tell me whether this fix (r152289) for issue #4425 is already merged to branch 1.8.x?!( Ivan's answer is not enough for me. Ivan wrote: Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. I don't know whether r1522892 is in trunk (I suppose this) or in destination branch 1.8.x. Yes, r1522892 was merged to 1.8.x branch and other user tested 1.8.x command line binaries (from TortoiseSVN) and confirmed that issue fixed: http://svn.haxx.se/users/archive-2013-10/0110.shtml -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Outlook macro for proper quoting (was RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?)
From: Andrew Reedick From: Geoff Field Sent: Wednesday, September 25, 2013 7:27 PM Hi Bert, From: Bert Huijben Sent: Wednesday, 25 September 2013 21:04 PM I'll just reply in the html form as it will be very hard to convert this thread to plain ascii and I have better things to do than spending half an hour on that. As much as Outlook (and I know you're using Outlook because the headers of your message include X-Mailer: Microsoft Outlook 15.0) is a sub- optimal tool for traditional groups, it's not that hard to change the Format selection from HTML to Plain Text. The real problem/pain is that you then have to reformat the message to make sense in plain-text format. I haven't done much to this message and it's a bit of a mess. For those suffering from the embarrassment of posting with Outlook clients: QuoteFix Macro at http://sourceforge.net/apps/mediawiki/macros4outlook/index.php?title=QuoteFix_Macro#Configuration Thanks Andrew, I've found that with a very small effort and a little manual configuration, I can produce a reasonably formatted post without upsetting the modern conventions used by most of the others within our business. Having said that, I've applied QuoteFix on my Outlook Express at home (some time in the past). I'm reluctant to apply it on my work computers, though - if our firewall even allows downloads from SourceForge (it's a bit fussy in some very odd ways). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Recommendation for path-based authorisation auditing tool?
Hi David, I hate to sound like I'm stating the bleeding obvious, but what about just looking at the authz file with a text editor? It's not hard to interpret if your usernames are sensible. I've recently spent a little while making sure the projects are sorted in a sensible order, so finding particular projects is quite easy (apart from just using the built-in search functions). Having said that, we use a home-grown tool (written by a long-gone colleague in C# and backed by an SQL database for administration items) for some network administration tasks. Mostly, this is useful as a lazy way of adding or deleting projects. I still use the text editor for modifying user permissions (because it's faster and easier). Regards, Geoff From: David Aldrich Sent: Friday, 27 September 2013 1:08 AM Hi Mark Thanks, that's a very helpful suggestion. Best regards David From: Mark Phippard Sent: 26 September 2013 16:06 On Thu, Sep 26, 2013 at 11:02 AM, David Aldrich wrote: Hi Mark Thanks for replying. By auditing, I mean the ability to easily see who has access to a specified folder. I think we already have the recording of changes covered. svnauthz_accessof looks interesting, but it reports whether a specified user has access. I would prefer to ask 'who has access?' to a specified folder. OK. I am not aware of any tools commercial or otherwise that provide the information that way. If you use groups and have a finite number of them, it seems like it would be a fairly simple script to check each group against the path using the command line tool and report which ones have access. -- Thanks Mark Phippard http://markphip.blogspot.com/ -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Good evening Thorsten, Guten Tag Geoff Field, am Mittwoch, 25. September 2013 um 02:25 schrieben Sie: Hi Bert,[...] Please don't rely on everyone is seeing HTML mails by default, My apologies. My only excuse (apart from laziness) is that the post to which I replied was in HTML. I don't and your answer is almost useless as plain text. And I thought *I* was a throwback ;-) http://www.netmeister.org/news/learn2quote.html There's a difference between being taught and learning. The latter relies on actually *remembering* what a teacher has tried to hammer through one's skull. For those who do not or will not run an email client with HTML capabilities turned on, here is the post in plain text format: From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Wednesday, 25 September 2013 6:43 AM To: 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? There is no issue for this specific part of those threads created as nobody was able to produce a reproduction recipe for this problem to the developers yet. Surely it would be useful to add the issue report anyway, even if there is no easy way to reproduce it. After all, it is a known issue now. We can then work on the reproduction recipe. All the threads you quoted end with this request. So unless you add a way to reproduce the problem (perhaps with the help of the earlier reporters) to the discussion there is not much we can do for you at this time/ I'm sure I posted the method for me to reproduce it.We were running a 1.2.3 server served by Apache 2.0.54 on Windows Server 2003 SP2. I was then using a 1.8.1 client on Windows 7 Pro 32-bit. I thought I'd posted my recipe here: http://svn.haxx.se/users/archive-2013-08/0035.shtml However, this is NOT the full recipe. Instead, look at this post: http://svn.haxx.se/users/archive-2013-08/0140.shtml That contains the steps I took to reliably produce errors with the server/client setup we had. Unlike most of our repositories, the Playground repo has always been FSFS. The problem happened with our BDB repos as well. The problem doesn't reproduce with the currently supported versions, nor with the older versions we tried to setup specifically to trigger the problem quoted here. But it's easily reproduced here, and obviously is at other sites too. Do you see the problem in all working copies, or just in certain scenarios? (E.g. multiple levels of added directories? Mixed revision copies? Etc. etc.) I saw it in nearly every case. There were rare occasions when the add/commit would just work, but in the majority of cases it would fail. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Hi Bert, From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Wednesday, 25 September 2013 21:04 PM To: Geoff Field; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? I'll just reply in the html form as it will be very hard to convert this thread to plain ascii and I have better things to do than spending half an hour on that. As much as Outlook (and I know you're using Outlook because the headers of your message include X-Mailer: Microsoft Outlook 15.0) is a sub-optimal tool for traditional groups, it's not that hard to change the Format selection from HTML to Plain Text. The real problem/pain is that you then have to reformat the message to make sense in plain-text format. I haven't done much to this message and it's a bit of a mess. The information in your e-mail says that you can reproduce it on your working copy; and then Philip Martin says he can't reproduce it. I've given as much detail as I can in the various emails, but I think Philip has had problems getting the exact version loaded. I looked through your apache log (attached in yet another followup) and noticed that about every request first fails with a 401 error and then later succeeds. Yes, that seems to be happening a lot. Even now after updating versions I'm getting a lot of 401s in the log. What authentication configuration does your apache use? We're using an authz file. Specifically, we have: Location /Subversion/ Options Indexes FollowSymLinks DAV svn SVNListParentPath On SVNParentPath L:/Subversion/Repositories SSLRequireSSL # Keep these in sync with location /websvn below AuthType SSPI # AuthType None AuthName Subversion repositories SSPIAuth On SSPIAuthoritative On SSPIDomain AAPL SSPIOfferBasic On Require valid-user AuthzSVNAccessFile L:/Subversion/conf/svnaccessfile.conf /Location And yes, I've just double-checked that the /websvn location is identical. NTLM/Digest/Basic, with what backend. Our LoadModules for auth connections include the following lines (omitting the commented-out ones): LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule sspi_auth_module modules/mod_auth_sspi.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_svn_module modules/mod_authz_svn.so On the server, the Services applet gives the following Description information for Apache 2 (which is no longer active because it's where we get the problems): Apache/2.0.54 (win32) DAV/2 mod_ssl/2.0.55 OpenSSL/0.9.8 SVN/1.2.3 mod_python/3.1.3 Python/2.3.5 PHP/5.0.4 mod_auth_sspi/1.0.3 If I've missed anything important, please feel free to give me more detailed information on what you need. What is the maximum number of requests per connection? I'm not entirely sure. From the Apache2 httpd.conf, I see: IfModule mpm_winnt.c ThreadsPerChild 250 MaxRequestsPerChild 0 /IfModule I'm not entirely sure if the mpm_winnt module is enabled. Can you send us your apache config (with sensitive information replaced by dummy information of course) I'll reply off-list with the full httpd.conf for Apache2. There is nothing in there that I consider secret. The authz file is another story, of course, but I'll send a copy of that with just the Playground repo information. Thanks, Bert And thanks for your attention and patience, too. Regards, Geoff From: Geoff Field [mailto:geoff_fi...@aapl.com.au] Sent: woensdag 25 september 2013 02:25 To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hi Bert, From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Wednesday, 25 September 2013 6:43 AM To: 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? No, There is no issue for this specific part of those threads created as nobody was able to produce a reproduction recipe for this problem to the developers yet. Surely it would be useful to add the issue report anyway, even if there is no easy way
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Thanks Bert, I appreciate the effort. (Top-posting, but at least it's in plain-text format...) Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Thursday, 26 September 2013 2:13 AM To: Geoff Field; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? I think I found a bug causing your specific problems in 'serf', Subversions new default http library. The problem doesn't appear to affect Subversion users unless the server closes connections aggressively. 'HEAD' requests (as requests without a body) don't trigger the authentication subsystem. The 401 from the HEAD request as shown in your log file is assumed to be a 'file exists' status. A patch is available on the serf development list. I assume it (or a similar patch) will be included in the next serf version. Bert From: Bert Huijben [mailto:b...@qqmail.nl] Sent: woensdag 25 september 2013 13:04 To: 'Geoff Field'; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? I'll just reply in the html form as it will be very hard to convert this thread to plain ascii and I have better things to do than spending half an hour on that. The information in your e-mail says that you can reproduce it on your working copy; and then Philip Martin says he can't reproduce it. I looked through your apache log (attached in yet another followup) and noticed that about every request first fails with a 401 error and then later succeeds. What authentication configuration does your apache use? NTLM/Digest/Basic, with what backend. What is the maximum number of requests per connection? Can you send us your apache config (with sensitive information replaced by dummy information of course) Thanks, Bert From: Geoff Field [mailto:geoff_fi...@aapl.com.au] Sent: woensdag 25 september 2013 02:25 To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hi Bert, From: Bert Huijben [mailto:b...@qqmail.nl mailto:b...@qqmail.nl ] Sent: Wednesday, 25 September 2013 6:43 AM To: 'JANIKOVIC Jan'; users@subversion.apache.org mailto:users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? No, There is no issue for this specific part of those threads created as nobody was able to produce a reproduction recipe for this problem to the developers yet. Surely it would be useful to add the issue report anyway, even if there is no easy way to reproduce it. After all, it is a known issue now. We can then work on the reproduction recipe. All the threads you quoted end with this request... So unless you add a way to reproduce the problem (perhaps with the help of the earlier reporters) to the discussion there is not much we can do for you at this time/ I'm sure I postedthe method for me to reproduce it.We were running a 1.2.3 server served by Apache 2.0.54 on Windows Server 2003 SP2. I was then using a 1.8.1 client on Windows 7 Pro 32-bit. I thought I'd posted my recipe here: http://svn.haxx.se/users/archive-2013-08/0035.shtml http://svn.haxx.se/users/archive-2013-08/0035.shtml However, this is NOT the full recipe. Instead, look at this post: http://svn.haxx.se/users/archive-2013-08/0140.shtml http://svn.haxx.se/users/archive-2013-08/0140.shtml That contains the steps I took to reliably produce errors with the server/client setup we had. Unlike most of our repositories, the Playground repo has always been FSFS. The problem happened with our BDB repos as well. The problem doesn't reproduce with the currently supported versions, nor with the older versions we tried to setup specifically to trigger the problem quoted here. But it's easily reproduced here, and obviously is at other sites too. Do you see the problem in all working copies, or just in certain scenarios? (E.g. multiple levels of added directories? Mixed revision copies
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Hi Bert, From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Wednesday, 25 September 2013 6:43 AM To: 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? No, There is no issue for this specific part of those threads created as nobody was able to produce a reproduction recipe for this problem to the developers yet. Surely it would be useful to add the issue report anyway, even if there is no easy way to reproduce it. After all, it is a known issue now. We can then work on the reproduction recipe. All the threads you quoted end with this request... So unless you add a way to reproduce the problem (perhaps with the help of the earlier reporters) to the discussion there is not much we can do for you at this time/ I'm sure I posted the method for me to reproduce it.We were running a 1.2.3 server served by Apache 2.0.54 on Windows Server 2003 SP2. I was then using a 1.8.1 client on Windows 7 Pro 32-bit. I thought I'd posted my recipe here: http://svn.haxx.se/users/archive-2013-08/0035.shtml However, this is NOT the full recipe. Instead, look at this post: http://svn.haxx.se/users/archive-2013-08/0140.shtml That contains the steps I took to reliably produce errors with the server/client setup we had. Unlike most of our repositories, the Playground repo has always been FSFS. The problem happened with our BDB repos as well. The problem doesn't reproduce with the currently supported versions, nor with the older versions we tried to setup specifically to trigger the problem quoted here. But it's easily reproduced here, and obviously is at other sites too. Do you see the problem in all working copies, or just in certain scenarios? (E.g. multiple levels of added directories? Mixed revision copies? Etc. etc.) I saw it in nearly every case. There were rare occasions when the add/commit would just work, but in the majority of cases it would fail. Bert From: JANIKOVIC Jan [mailto:jan.janiko...@power.alstom.com] Sent: dinsdag 24 september 2013 12:51 To: users@subversion.apache.org Subject: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hello, There seems to be a problem with the TortoiseSVN1.8.0+, which returns a server conflict when a new file is attempted to be added. We observed the problem only when adding files to the server running SVN1.5.5. No problems were observed when adding files to our second server, running SVN 1.7.x. There are further posts about this issue on the Internet, such as https://groups.google.com/d/topic/tortoisesvn/cGoClRBMCPc/discussion or https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ Is this issue already in the Subversion tracker (http://subversion.apache.org/reporting-issues.html)? If yes, could you please tell me the issue number Kind regards Jan Jan Janikovic ALPRO Implementation Specialist Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Breaking up a monolothic repository
From: Trent W. Buck Sent: Monday, 9 September 2013 12:17 PM Nico Kadel-Garcia nka...@gmail.com writes: Lock the existing repo: Do clean exports, and imports, to new repositories with the new layout, with a README.md or other guideline to where the legacy repository exists. You lose the infinitely preserved history this way, but for most working software projects, you don't *need* that. And it's a good opportunity to discard materials, such as bulky binaries or security sensitive files with plain text passwords. Ah, sorry, I forgot to mention that preserving history was a hard requirement handed down from higher up. You *could* argue that the existing repository preserves the history. However, I think I know what they mean. I get the impression that $company's projects mostly have a finite lifespan (a couple of years), By lifespan, what exactly do you mean? At my company, the individual projects might be in production within anywhere from 6 months to 2 years after start of development, be manufactured for two to four years, then go into support mode for up to 7 years (or more). so I think that approach ends up being very similar to my current plan of creating new projects as new repos, and letting the monolithic repo die out via attrition. That sounds like an easy way to do things. I don't actually know exactly what they put in their repos; I think it's about half huge unpacked source tarball I downloaded from somewhere then tinkered with and half huge CAD files and .docx contracts. It's entirely possible that the empty commit messages you reported were due to users not actually entering anything in the messages. Many of the commit messages I've seen (particularly from non-software people, but even from a few of those) are less informative than I'd like - a lot are totally empty. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN commit line ending handling
Hi Thorsten, Guten Tag Geoff Field, am Montag, 2. September 2013 um 01:09 schrieben Sie: If the file's encoded as UTF-16, it will give this error regardless of the consistency of the line endings. I successfully committed UTF-16 some minutes ago, Subversion doesn't care about the character set of the files. Last time I did a commit of this file, I was using TortoiseSVN version 1.7.13 (or earlier) on a Windows system. The properties include svn:eol-style=native and svn:mime-type=text/xml (this latter is probably from autoprops). The problem in your case surely was because of inconsistent line endings as well. It's possible. I did look at the file with a hex editor to try to fix things, but didn't see any inconsistent line endings. Of course, this does not mean there were none, just that I didn't see them. In the hex editor, the line endings were all encoded as 00 0d 00 0a. Given the native eol style, I think SVN might have been looking for 0d 0a without the padding. SVN might even have seen the 00 0d as one line ending and the 00 0a as the next. Since the file is auto-generated as part of an installation package, one would hope the auto-generation tool would make the endings consistent. However, hope is no substitute for reality. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN commit line ending handling
From: Ryan Schmidt Sent: Sunday, 1 September 2013 8:21 AM On Aug 31, 2013, at 05:29, Edoardo Pinci wrote: I periodically receive this kind of errors since a long time. X:\svn commit -m BLA BLA itextsharp.dll iTextSharp.xml SendingiTextSharp.xml Sendingitextsharp.dll Transmitting file data .. svn: E135000: Commit failed (details follow): svn: E135000: While preparing 'iTextSharp.xml' for commit svn: E135000: Inconsistent line ending style I've seen this a few times when committing an auto-generated XML file - mostly because it was encoded as UTF-16. svn: E720032: Additional errors: svn: E720032: Transaction '1718-1ca' cleanup failed svn: E720032: Can't remove file 'Depot\db\txn-protorevs\1718-1ca.rev': The process cannot access the file because it is being used by another process. Since I've been using the TortoiseSVN client, I haven't noticed whether these additional errors popped up as well. Question 1: Is there a way to have SVN normalize line ending on commit by itself? It seems svn:eol-style is set on this file. If you set svn:eol-style on a file (to any supported value), Subversion requires that the file have consistent line endings before you commit it. You or your tools must do this; Subversion will not. I was going to ask why not? However, I realised this is because the SVN philosophy is to not change files unless explicitly requested to (with keywords). If you do not set svn:eol-style, then Subversion does not check the line endings and lets you commit whatever you want, so if for some reason you want inconsistent line endings then that's how you can have that. If the file's encoded as UTF-16, it will give this error regardless of the consistency of the line endings. I've found the easiest way around this (for me) is to copy and paste the contents of the XML file into a new file encoded as UTF-8, then save it over the top of the original file. Notepad++ is my preferred option for this at the moment, but any text editor should do the job. Question 2: Why txn-protorevs aren't being cleaned up properly? I don't know what's going on there. Do you have any hook scripts? Maybe one of them is programmed incorrectly. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Unsubscribe
From: Andreas Mohr Sent: Wednesday, 28 August 2013 15:49 PM On Wed, Aug 28, 2013 at 03:07:15PM +1000, Geoff Field wrote: You need to send an email to [1]users-unsubscr...@subversion.apache.org to unsubscribe from this list. ...as can in most cases of mailing lists be determined via an email header line: || List-Unsubscribe: mailto:users-unsubscr...@subversion.apache.org || I don't know if our company filters stripped it out, but OutHouse^w OutLook did not show a header anything like this when I did the (ahem) *intuitive* View-Options trick. , if mail headers of a mail are viewable (which may unfortunately not be the case with less capable - ahem - MUAs). Some of us are stuck with what our IT departments give us to work with. If you want to work with an Exchange server, it's easiest (and most compatible) to work with Outlook - particularly if the PC has it preinstalled. In reality, Outlook is not that bad an email client - provided you don't want to do technical things with it. The integration with the calendar functionality is particularly valuable for those of us who lose track of time when working. Voting is a nice feature, too, that we sometimes use. Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Unsubscribe
Hi Brane, Outlook (and Exchange) have been known to strip headers that are not important to users. Micro$oft being helpful again... We do have the procedures documented here, however: http://subversion.apache.org/mailing-lists.html Which is where I dredged up the advice to the OP. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Unsubscribe
Hi Venkat, You need to send an email to users-unsubscr...@subversion.apache.orgmailto:users-unsubscr...@subversion.apache.org?subject=unsubscribe to unsubscribe from this list. Regards, Geoff From: Badipatla, Venkata [mailto:venkata.badipa...@capgemini.com] Sent: Wednesday, 28 August 2013 15:03 PM To: users@subversion.apache.org Subject: Unsubscribe Unsubscribe Thanks Regards, Venkat This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Planning a SVN upgrade
From: Mark Phippard Sent: Saturday, 24 August 2013 6:35 AM On Fri, Aug 23, 2013 at 4:09 PM, Maureen Barger wrote: I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. We have just upgraded our server from 1.2.3 to 1.8.1, including a move from Apache 2.0 to Apache2.2. It took me some time, but it was done as a bit of a background task. There were 74 BDB repositories that had to be dumped and loaded to FSFS format. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. If it were me, I would not upgrade the repositories. SVN 1.8 can just serve the old repositories. I would do the upgrade and only after I was using it for a while would I then consider to start doing a dump/load on the repositories. You could then do them one by one as desired. The main benefit in upgrading the repository is to use less disk space. I also would not upgrade existing repositories just for the sake of it. If there's a feature you feel would be useful that's only available with the 1.8 repo format, then I would do it, but ONLY for the active repos. The only reason I upgraded the BDB repositories was because I could no longer access them with the new server software. Even then, I left them in the 1.2 format in case we had to go back to the original server for some reason. If you're going to do an upgrade on the repositories, make sure you back them up first. Then the disk space issue becomes moot, because the backups take space as well. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. Yes, your clients can already be using 1.8 if they want to. There is no need to upgrade the client either before or after the server. Let the clients manage it. Only exception is if there are specific new features you want to implement across the board. If you do a lot of branching and merging, it would be a good idea for the people that do merge to all be using the same version. Likewise, there are other features that might be like this. I concur. (Of course, Mark has a lot more SVN experience and in-depth knowledge than I do.) Leave it to the individual to decide whether to upgrade. There are very few cases where the server and client software are incompatible between versions. Mind you, I did have to do our upgrade to the server because version 1.8.x of the client doesn't play nicely with version 1.2.x of the server, in terms of adding new files and displaying logs. That's how I came to join the mailing lists in the first place. I do not foresee any changes I would need to make to Jenkins or Nexus. Just the URL to access the repository will change. Even that doesn't have to change. We're using the same URLs. Has anyone made a jump this large before? Any comments about my upgrade plan? There is nothing unusual about this. People have jumped from 1.1 to 1.8. In my case, 1.2 to 1.8. By comparison, 1.5 to 1.8 should be easy. Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Hi Thomas, From: Thomas Harold Sent: Friday, 23 August 2013 1:25 AM On 8/21/2013 7:13 PM, Geoff Field wrote: I'm keeping the original BDB repositories, with read-only permissions. If I really have the need, I can restart Apache 2 with SVN 1.2.3 and go back to the original repositories When we did our 1.6 to 1.8 upgrade a few weeks ago, I used the following steps (ours was an in-place upgrade, so a bit of extra checking was added): 0. Back everything up, twice. Our servers have nightly backups that I know to work (from experience). I also didn't get rid of the originals (as stated). 1. Check the version of the repository to see whether it is already 1.8 I *knew* that all of our repositories were in the 1.2 format. That's the only version we had for years on end. ... 2. Strip permissions on the original repo down to read-only. I didn't bother with that, since I didn't do any write operations on the repos (other than changing the names. However, I *did* change the repo access permissions in the authz file. 3. Ran svnadmin verify on the original repository. Probably something I should have done, but luckily I ended up with no obvious failures in the dumps. 4. Do the svnadmin dump, piping the output into gzip -5 (moderate compression). If you're removing the old repo, I suppose it makes sense to keep the dump file. Compression would make it less onerous in storage terms. 5. Remove the old repository directory. I agree with what the script echoes - dangerous 6. Create the repository in svn 1.8. I'm sure there's an upgrade command that would do it all in-place. 7. Strip permissions on the repository back down to 700, owned by root:root while we reload the data. While, or before? 8. Fix the db/fsfs.conf file to take advantage of new features. Note: Make sure you understand what enable-dir-deltification, enable-props-deltification and enable-rep-sharing do. Some of these are not turned on in SVN 1.8 by default. There are features we're very unlikely to need at this stage in our company existence. 9. Load the repository back from the dump file. At last! 10. Run svnadmin pack to pack revs/revprops files (saves on inodes). Makes sense 11. Run svnadmin verify. Always a good thing to do. 12. Restore original permissions. Fair enough. Note: I have a custom script that I can run to set permissions correctly on our repository directories. I never set file system permissions by hand on the repositories, I always update the script and then use that. (With a few hundred repositories, I have to be organized and rely on scripts.) On your OS, is there a way to read the permissions first? 13. Back everything up again, twice. You're not paranoid if they really *are* out to get you... ;-) All-in-all, it took us a few days to convert 110GB of repositories (mostly in 1.6 format), but the resulting size was only 95GB and far fewer files (due to revprops packing in 1.8). Our nightly backup window went from about 3 hours, down to 30 minutes from using svnadmin hotcopy --incremental. When then use rdiff-backup to push the hotcopy directory to a backup server. I've just surprised myself by checking the file system properties. After the BDB-FSFS conversion, we now have 164 repositories, totallying 312GB on the disk. That's a LOT of backup space requirement. Luckily for me, that's all handled by our IT department and is done on their SAN via an automatic utility. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
From: Thomas Harold Sent: Friday, 23 August 2013 11:53 AM On 8/22/2013 7:11 PM, Geoff Field wrote: Most restores for us took about 5-10 minutes, a few of our larger repos took a few hours. I was doing this all in the background via remote login to our SVN server, so I didn't monitor times. Some of our repos only took seconds because there wasn't much to load. The ones that involved more people and more changes took up to somewhere on the order of an hour or so. Usually, I'd just set it going and do other work while occasionally glancing at the remote desktop session to see if it had finished the current step. Since we use svn+ssh, repository permissions matter a bit more for us. We only allow https access and we only have a few users now, so monitoring and controlling access during the changeover was easy. Besides, nobody was ABLE to access the BDB repositories because the more recent server builds that you can download don't include the BDB module. Simply stopping the old server software was enough to kill all access to the BDB repositories in our case. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How Big A Dump File Can Be Handled?
From: Ben Reser Sent: Wednesday, 21 August 2013 12:12 PM On Tue Aug 20 16:44:08 2013, Geoff Field wrote: I've seen some quite large dump files already - one got up to about 28GB. The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right now, our largest repository (some 19,000 revisions with many files, including installation packages) is dumping. In the 5300 range of revisions, the dump file has just passed 9GB. Overall, it got to about 29GB. Dump and load worked fine, although they got a bit slow towards the end. (In fact, I delayed sending this until it had actually finished.) Shouldn't be a problem within the limits of the OS and filesystem. I've just realised that my concern was based on a power-of-2 limitation that means that a 32-bit signed integer would roll over at the 2GB mark, with an unsigned roll-over at 4GB. It's possible the Windows Server 2003 file system might have started to complain when it ran out of block indices/counters or some such, but there's no reason a 32GB+ file won't work if 4.1GB or more works. However, I'd say why are you bothering to produce dump files? Why not simply pipe the output of your dump command to a load command, e.g. svnadmin create newrepo svnadmin dump --incremental oldrepo | svnadmin load newrepo I've been working in Windoze too long - I failed to think of that option. I'll use that for the rest of the repositories (about 19 remain to be done). Thank you for that application of the clue-by-four. You've made the rest of my task a lot easier. I really should have done it all using a scripting language of some sort, too. I've told myself it's really too close to the end of the process to think of *that* change now, except I've just managed to quickly throw together a batch file to do the job. I could probably have done it in python or some other scripting language, but batch files are quick and easy. Again, thanks Ben for the prompt to use my head a bit better (even though you didn't explicitly suggest this aspect). CopyBDBToFSFS.bat: rem Create a new repository - using the OLD format just in case we need to switch back to the old server C:\Program Files\Subversion\bin\svnadmin.exe create %1_FSFS rem Copy the data from the old repository to the new one C:\Program Files\Subversion\bin\svnadmin.exe dump --incremental %1 | C:\Program Files\Subversion\bin\svnadmin.exe load %1_FSFS rem Change the names to make the new repository accessible using the existing authentication and URLs and the old one accessible for emergency use. ren %1 %1_BDB ren %1_FSFS %1 rem Check the new repository with the current tools to confirm it's OK. svnadmin verify %1 Note that we have the old version 1.2.3 server software installed at the C:\Program Files\Subversion location, and later versions are stored under other locations, with the path set to point to the new version. I'm creating the new repositories with the old version for those (hopefully rare) occasions when we need to switch back to the old server version. You'll need space for two repos but that should be less than the space the dump file will take. We're keeping the old repos anyway, just in case. We're an automotive parts company with support requirements for some quite old versions, so we can't afford to throw away too much history. Even though it's a RAID system (using Very Expensive disk drives, so it's actually a RAVED system), there's lots of space available on the drive where the repositories live. I included the --incremental option above because there's no reason to describe the full tree for every revision when you're doing a dump/load cycle. That makes sense. You can save space with --deltas if you really want the dump files, but at the cost of extra CPU time. If you're just piping to load the CPU to calculate the delta isn't worth it since you're not saving the dump file. I agree. The server's not particularly new, so if I can save on processor time that's a good thing. I'm discarding/reusing the dump files anyway, since we're keeping the original repositories (and we have a separate backup system for the servers - I know it works too, because I've had to restore some of the BDB repositories from it). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately
RE: How Big A Dump File Can Be Handled?
From: Ben Reser Sent: Wednesday, 21 August 2013 17:07 PM On 8/20/13 11:29 PM, Geoff Field wrote: Note that we have the old version 1.2.3 server software installed at the C:\Program Files\Subversion location, and later versions are stored under other locations, with the path set to point to the new version. I'm creating the new repositories with the old version for those (hopefully rare) occasions when we need to switch back to the old server version. I should have added that any new repositories are being created with the new version of the tools. The old server software is only being kept around for legacy stuff. You can create old format repositories with the new tools via the following flags to create: --pre-1.4-compatible --pre-1.5-compatible --pre-1.6-compatible and with 1.8 (when we got a clue that the above was getting silly): --compatible-version Handy to know. I recall seeing that sort of thing go flying by on the lists recently. One of these days I might have cause to use it. So you don't actually need to keep old versions of svnadmin around in order to do that. But to work with the BDB repositories (just in case I ever have to again), I will still need the old version of svnadmin. Given that we're one of those companies that get audited for process conformance (we're in the middle of one right now), it's better to be safe than sorry. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How Big A Dump File Can Be Handled?
From: Thorsten Schöning Sent: Wednesday, 21 August 2013 17:21 PM Guten Tag Geoff Field, am Mittwoch, 21. August 2013 um 08:29 schrieben Sie: I've just realised that my concern was based on a power-of-2 limitation that means that a 32-bit signed integer would roll over at the 2GB mark, with an unsigned roll-over at 4GB. It's possible the Windows Server 2003 file system might have started to ... You didn't seriously thought that a Windows Server 2003 has such limitations?! If you installed on FAT32 you made something really wrong. ;-) Ah, but it wasn't ME that did the install. I really should have done it all using a scripting language of some sort, too. I've told myself it's really too close to the end of the process to think of *that* change now, except I've just managed to quickly throw together a batch file to do the job. ... I created a powershell script to convert my 1.4 repos to 1.7 some months ago, few months later we moved all repos to our Ubuntu development server and last month or so I upgraded svn to 1.8, without the possibility of a full dump/load because of my not working script anymore. One shouldn't start with platform specific console scripting anymore unless it's about really trivial stuff. It's to easy these days to change platforms. To me, the copy is pretty trivial (if somewhat tedious) and unlikely to be repeated. Changing platforms, however, would be distinctly NON-trivial in our circumstances. The servers are administered by a whole other department, with their platform inertia somewhat built-in. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: How Big A Dump File Can Be Handled?
From: Nico Kadel-Garcia Sent: Thursday, 22 August 2013 8:10 AM I would never do a transfer like this without a copy of the dumpfile available, for reference. The pain of having to re-run the dump later, especially if there are any bugs in the svnadmin load configuration, normally justifies keeping the dump around until well after the migraiton is completed. Hi Nico, I'm keeping the original BDB repositories, with read-only permissions. If I really have the need, I can restart Apache 2 with SVN 1.2.3 and go back to the original repositories. Otherwise, I also have the option of re-running my batch file (modifying it if absolutely required). On top of that, there are bunches of files on another server that give us at least the latest state of the projects. The dump files in this case are not really as useful as the data itself. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
How Big A Dump File Can Be Handled?
Just a query out of curiosity: I'm currently in the process of migrating all 74 of our BDB repositories to FSFS via a dump/create/load cycle. I've seen some quite large dump files already - one got up to about 28GB. The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right now, our largest repository (some 19,000 revisions with many files, including installation packages) is dumping. In the 5300 range of revisions, the dump file has just passed 9GB. Am I going to run into problems, or is it open-ended? This probably comes down to the data type of the file index parameters/variables. I guess I'll find out soon enough, as the dump churns away (and, if/when that succeeds, the subsequent load churns through). Just in case any developer is on hand during my work day here in Australia, it might be nice to know. I'll let the list know if there's a crash during the process, too. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department. - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
From: Nico Kadel-Garcia Sent: Friday, 16 August 2013 21:39 PM To: Geoff Field Cc: Philip Martin; users@subversion.apache.org Subject: Re: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME) Get your legacy material off BDB and onto FSFS, ASAP. At least make sure you have *good* backups and are prepared to lose all that data if you don't. BDB has been, in my experience with much older versions of Subversion and with years of Linux application experience, prone to data corruption from unpredictable and unrecoverable userland events and even the slightest blip of the OS or hardware layer. It has also repeatedly proven impossible to upgrade existing data sets to new BDB releases in place. Subversion fortunately has a workable backup system to provide data transfers: I've seen BDB systems that did not. Thanks for the opinion Nico. I'm in the middle of doing the translation now. As I said, though, we have about 100 repositories, most of them in BDB format, so it's no small task. The servers are backed up nightly using IBM's Tivoli Storage Manager. I've had to recover repositories a few times using that tool, so I know it works for us. BDB has never been my friend. We've had a few corrupt repositories over the years. We got to the stage where we wrote an internal Wiki page on fixing corrupt repositories. We had a colleague write an application to help with management of the repos. Unfortunately, he chose to create them in BDB format. That's why we have so many BDB repositories. Rather than recreate the build environment and rebuild the management application, I've edited the EXE file to replace the (DBCS) string that sets the format with spaces. Geoff On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field wrote: From: Geoff Field Sent: Friday, 16 August 2013 11:56 AM Thanks to everybody for their patience with my issue. The root cause is not really solved, but at least I (and my colleagues) can get back to normal work patterns. I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 running. As it turns out, my former colleagues had deliberately configured all the ports one up from the default (thus, SSL was running on port 444 instead of the default 443). Once I'd fixed this, Apache 2.2 started serving SVN via the default interfaces. With that, I can now run everything happily. It seems I spoke too soon. It turns out that the updated SVN server 1.6.9 works for those few of our repositories that are in FSFS format. Unfortunately, our legacy repositories are almost all in BDB format and I'm loathe to touch them if I can avoid it. Building SVN from source is not really a useful option, but we can do it (with a struggle) if we absolutely have to. Frankly, I'd rather convert all the repositories (and there are 100 all up, although some are in FSFS format already) than build the server code. Has anybody built a version that handles BDB in a DAV module? I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should be able to switch back to that if needed. I suppose it's possible some repositories might become inaccessible to the earlier server due to the server upgrade, but I'm not particularly fussed about that. We can swap back to the other version fairly easily if we have to, just by stopping Apache2.2 and starting Apache2 (or vice-versa). Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Are there SVN consultants out there who remember the ol' days?
Hi Dana From: Dana Epp Sent: Saturday, 17 August 2013 4:47 AM We have an old SVN database corruption we need help with. (SVN 1.1 with BDB 4.2) Does anyone know of someone who consults on this sort of thing? We've been dealing with SVN 1.2.3 for a long time, and have developed a process for dealing with corrupted databases. Below is a copy from our (internal) Wiki page. I hope it helps you and others. Regards, Geoff Recovering Corrupted Repositories Simple Corruption (Log File) Very occasionally, a file is committed to a repository which causes the repository to be corrupted. This usually manifests itself as access to the repository freezing. See the extensive notes in Mantis Issue 7585 . Here are the steps required to recover: Warn everybody that SubVersion is about to go down! Remember that some repositories may not be corrupt. Locate a drive with sufficient spare space for the affected repositories Log onto the SubVersion server. This requires administrative access, which is limited to a very small number of people. Stop the Apache service Backup the affected repositories Remove the log files which don't have the db version as 0x0A in the 16th byte of the offending log file. For example, log.02030 had a db version of 0x0b. Run db_recover from within the db directory of the repository. This requires the utility to be in the path (C:\Program Files\Sleepycat Software\Berkeley DB 4.3.29\bin) Run svnadmin recover .\ from within the repo directory (i.e. one above the db dir) Re-start the Apache service Inform everybody that SubVersion is back up. Note Sometimes db_recover does not work. In this case, the -c flag helps for critical errors Serious Corruption (Database) From http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065dsMessageId=1617554 Nicholas Walker NWalker at dialogue-marketing dot com Full name Nicholas Walker NWalker at dialogue-marketing dot com Date 2009-04-09 13:31:59 PDT Message I went through a week of trying to resolve various issues with an old out of control corrupted v 1.4 Berkeley Db subversion repository. These steps will not work for an fsfs repository. I put together a process for how I resolved my issues. I hope it helps somebody else out. Note: This process does not solve corruption, it just puts the repository into a state where svnadmin dump will not fail. The steps below will result in specific histories being lost. If you have the option to go back to recent backup to resolve the issue that would be a much better strategy. But when the repository has not been maintained for ears as in my case there is no other way. You'll need to use the Berkeley db utilities that match the version of Berkeley db that is being used in your repository in my case those utilities were found in /usr/local/bin/db42. The path , and executables on your machine may not match mine. Copy repository to a temporary location. You can use svnadmin hotcopy REPOS_PATH NEW_REPOS_PATH Resolve pure database corruption This resolves error similar to DB_PAGE_NOT_FOUND error. There are files in [repository Path]/db Changes Copies Nodes Representations Revisions Strings Transactions uuids Each of these represent a database table Run /usr/local/bin/db42/db_dump -r File File.dump against each of the files. This dumps the database table to a dump file, and removes instances where corruption has occurred. Note that this will remove corrupted file commits from the database table, but they were irrecoverable anyway so it doesn't matter. If you have a large repository the dump and reload process make take a considerable amount of time, especially for the strings table. Run rm [File] for each of the files. Delete the file not the .dump file Run /usr/local/bin/db42/db_load File File.dump for each of the files. This is wonderful in theory, but I have found that the version of db_load we currently have does not like the format of the file output by db_dump on Windows: db_dump puts CR/LF on the end of each line, while db_load does not like this. To correct this: Open the file in Notepad++ View the file in Hex (Alt-Ctrl-Shift-H) Highlight the first 0d 0a. Select Search-Replace (Ctrl-H) Enter 0d (that's number 0, not letter O) in the Replace with field Click on Replace All Save the file. Since the process takes a long time, you may want to make a backup of your backup in case you mess up in the next steps, you have a half way point to revert to, since step 2 can take a long time.
RE: svn 1.8.1 fails on underscore in the tunnel protocol
From: Bert Huijben Sent: Saturday, 17 August 2013 9:18 AM From: Branko Čibej Sent: vrijdag 16 augustus 2013 23:29 On 16.08.2013 23:10, Eric Hall wrote: Hello- We have a custom tunnel protocol withrepository URLs of the form: svn+foo_bar:// After upgrading from svn 1.7.x to 1.8.1, these URLs are considered invalid, giving an error of: svn: E17: Illegal repository URL This occurs on an 'svn up' or an 'svn checkout'. Changing the tunnel protocol name to 'foobar' (i.e. drop the underscore) appears to work properly, both 'svn up' and 'svn checkout' work fine. Is this a bug, or should tunnel protocols not have underscores in them? See RFC 3986, section 3.1: http://www.ietf.org/rfc/rfc3986.txt Underscores are not allowed in the URL scheme. It would appear that allowing them was a bug in previous versions of Subversion. Reading through that RFC, I note the following paragraph: 2.3. Unreserved Characters Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde. unreserved = ALPHA / DIGIT / - / . / _ / ~ To me, this quite clearly states that underscores ARE permitted in URLs. Any code that fails to allow them is contrary to the RFC. The related change was not in Subversion itself, but in apr-util 1.5.2. [[ *) apr_uri_parse(): Do not accept invalid characters in the scheme. Per RFC 3986 3.3, enforce that the first segment of a relative path does not contain a colon. PR 52479. ]] That's about a colon, not an underscore. Regards, Geoff -- Apologies for the auto-generated legal disclaimer. - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
From: Geoff Field Sent: Friday, 16 August 2013 11:56 AM Thanks to everybody for their patience with my issue. The root cause is not really solved, but at least I (and my colleagues) can get back to normal work patterns. I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 running. As it turns out, my former colleagues had deliberately configured all the ports one up from the default (thus, SSL was running on port 444 instead of the default 443). Once I'd fixed this, Apache 2.2 started serving SVN via the default interfaces. With that, I can now run everything happily. It seems I spoke too soon. It turns out that the updated SVN server 1.6.9 works for those few of our repositories that are in FSFS format. Unfortunately, our legacy repositories are almost all in BDB format and I'm loathe to touch them if I can avoid it. Building SVN from source is not really a useful option, but we can do it (with a struggle) if we absolutely have to. Frankly, I'd rather convert all the repositories (and there are 100 all up, although some are in FSFS format already) than build the server code. Has anybody built a version that handles BDB in a DAV module? I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should be able to switch back to that if needed. I suppose it's possible some repositories might become inaccessible to the earlier server due to the server upgrade, but I'm not particularly fussed about that. We can swap back to the other version fairly easily if we have to, just by stopping Apache2.2 and starting Apache2 (or vice-versa). Regards, Geoff -- Geoff Field Testing Coordinator, Work Health Safety Rep, Chief Fire Warden, First Aider Australian Arrow Pty Ltd www.australianarrow.com.au 46 Lathams Rd, Carrum Downs, Vic, 3201, Australia phone (+61-3) 97850597, fax (+61-3) 9785 0583 GYNET x-067-597 - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Thursday, 15 August 2013 19:02 PM Geoff Field writes: I've just commented out the AuthzSVNAccessFile line and have done the following: This time, I changed the AuthType line to AuthType None for the Subversion location. Similar test (but with fewer typos this time). C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test7.txt ASVN_Test\test.txt Checked out revision 898. C:\cd SVN_Test C:\SVN_Testcopy test.txt test9.txt 1 file(s) copied. C:\SVN_Testsvn add test9.txt A test9.txt C:\SVN_Testsvn ci test9.txt --message test9 Adding test9.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test9.txt' is out of date svn: E175005: File 'test9.txt' already exists C:\SVN_Testsvn ci test6.txt --message test 1.8.1 checkin Adding test6.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date svn: E175005: File 'test6.txt' already exists Same error report persisting. 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1 201 439 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] HEAD /Subversion/Playground/trunk/test6.txt HTTP/1.1 401 - 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1 204 - That still shows 401 unauthorized which is odd if you are not using Authz. Do you have some other authz beyond AuthzSVNAccessFile? It could be the SSL layer. The location section does contain the following line: SSLRequireSSL Still showing: ... 0.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:24 +1000] CHECKOUT /Subversion/Playground/!svn/ver/898/trunk HTTP/1.1 201 439 10.63.36.64 - - [16/Aug/2013:09:39:25 +1000] HEAD /Subversion/Playground/trunk/test9.txt HTTP/1.1 401 - 10.63.36.64 - - [16/Aug/2013:09:39:26 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 401 580 10.63.36.64 - - [16/Aug/2013:09:39:27 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:27 +1000] DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1 204 - The 1.2.3 client simply shows that with neon we don't send HEAD. Again, the error log did not change. You may get more information if you add LogLevel debug I did that, too. I'll email the full results privately, as the 3000-odd lines resulting from this set of transactions is a bit too big for a group email. The final sections of the error log say this, though: ... [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1490): +-+ [Fri Aug 16 09:39:25 2013] [info] Subsequent (No.11) HTTPS request received for child 249 (server aapleng1.aapl.com.au:443) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#1114588 [mem: 121bae8] [Fri Aug 16 09:39:25 2013] [info] Connection to child 248 established (server aapleng1.aapl.com.au:443, client 10.63.36.64) [Fri Aug 16 09:39:25 2013] [info] (70014)End of file found: SSL input filter read failed. [Fri Aug 16 09:39:25 2013] [info] Seeding PRNG with 136 bytes of entropy [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL negotiation finished successfully [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1776): OpenSSL: Handshake: start [Fri Aug 16 09:39:25 2013] [info] Connection to child 249 closed with standard shutdown(server aapleng1.aapl.com.au:443, client 10.63.36.64) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1784): OpenSSL: Loop: before/accept initialization [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1512): OpenSSL: read 11/11 bytes from BIO#112df18 [mem: 52345e0] (BIO dump follows) [Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1459): +-+ ... [Fri Aug 16 09:39:27 2013] [info] Subsequent (No.2) HTTPS request received for child 248 (server aapleng1.aapl.com.au:443) [Fri Aug 16 09:39:27 2013] [info] [client 10.63.36.64] Access granted: 'AAPL\\gf' DELETE Playground: [Fri Aug 16 09:39:27 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#112df18 [mem: 52345e0] [Fri Aug 16 09:39:27 2013] [info] (70014)End of file found: SSL input filter read failed. [Fri Aug 16 09:39:27 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL
RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
Thanks to everybody for their patience with my issue. The root cause is not really solved, but at least I (and my colleagues) can get back to normal work patterns. I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 running. As it turns out, my former colleagues had deliberately configured all the ports one up from the default (thus, SSL was running on port 444 instead of the default 443). Once I'd fixed this, Apache 2.2 started serving SVN via the default interfaces. With that, I can now run everything happily. I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should be able to switch back to that if needed. I suppose it's possible some repositories might become inaccessible to the earlier server due to the server upgrade, but I'm not particularly fussed about that. Regards, Geoff -- Geoff Field - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Wednesday, 14 August 2013 9:59 AM Geoff Field writes: When I try to reproduce the problem I get a HEAD request that generates 404 not found rather than 401 unauthorized. What sort of authentication have you configured? Are you using path-based authz? Here's what I think is the relevant section of our httpd.conf: Location /Subversion DAV svn SVNParentPath L:/Subversion/Repositories SVNAutoversioning on AuthType SSPI AuthName Subversion repositories Require valid-user SSPIAuth On SSPIAuthoritative On SSPIDomain AAPL SSPIOfferBasic On SSLRequireSSL # SSPIUsernameCase lower ## Breaks authentication # SSPIPerRequestAuth Off ## This breaks Apache2 AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf Note that we're running Apache 2.0. Here are the exact details from the server's Services applet: If you could disable AuthzSVNAccessFile, or move the test repository to another Location that doesn't have authz, and then try the commit we could determine whether Subversion's authz is the problem. The apache error log may also have some relevant information about the 401. I've just commented out the AuthzSVNAccessFile line and have done the following: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testcopy test.txt test6.txt 1 file(s) copied. C:\SVN_Testsvn ci test6.txt --message test 1.8.1 checkin svn: E29: Commit failed (details follow): svn: E29: 'C:\SVN_Test\test6.txt' is not under version control C:\SVN_Testsvn add test6.txt A test6.txt C:\SVN_Testsvn ci test6.txt --message test 1.8.1 checkin Adding test6.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date svn: E175005: File 'test6.txt' already exists C:\SVN_Test That first ci is a procedural error, but I left it in for completeness. The Apache error log DID NOT change at all. No new entries were added by the test. The new Apache access log entries are as follows: 10.63.36.69 - - [15/Aug/2013:10:31:10 +1000] GET / HTTP/1.1 200 28508 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 200 201 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 200 97 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/trunk HTTP/1.1 207 712 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1 207 426 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1 207 481 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/bc/897/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/bc/897/trunk HTTP/1.1 207 343 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 200 201 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] OPTIONS /Subversion/Playground/trunk HTTP/1.1 200 97 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/trunk HTTP/1.1 207 712 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1 207 426 10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] PROPFIND /Subversion/Playground/!svn
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Tuesday, 13 August 2013 19:59 PM Geoff Field geoff_fi...@aapl.com.au writes: -Original Message- From: Philip Martin Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes: I can't reproduce that. Can you look in the apache log files to see the failed request? Can you reproduce the problem over http? Can you provide a network trace? I have emailed Philip and Lieven directly with the network trace file as it's a bit big (600-odd K) for a mailing list. It's an https trace so not much use to me. That's a shame. 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] PROPPATCH /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8 97 HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] PROPPATCH /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8 97 HTTP/1.1 207 475 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1 401 580 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1 201 439 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] HEAD /Subversion/Playground/trunk/test4.txt HTTP/1.1 401 - When I try to reproduce the problem I get a HEAD request that generates 404 not found rather than 401 unauthorized. What sort of authentication have you configured? Are you using path-based authz? Here's what I think is the relevant section of our httpd.conf: Location /Subversion DAV svn SVNParentPath L:/Subversion/Repositories SVNAutoversioning on AuthType SSPI AuthName Subversion repositories Require valid-user SSPIAuth On SSPIAuthoritative On SSPIDomain AAPL SSPIOfferBasic On SSLRequireSSL # SSPIUsernameCase lower ## Breaks authentication # SSPIPerRequestAuth Off ## This breaks Apache2 AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf Note that we're running Apache 2.0. Here are the exact details from the server's Services applet: Apache/2.0.54 (Win32) DAV/2 mod_ssl/2.0.55 OpenSSL/0.9.8 SVN/1.2.3 mod_python/3.1.3 Python/2.3.5 PHP/5.0.4 mod_auth_sspi/1.0.3 I'm trying (as a background task from my regular job) to upgrade to Apache 2.2, but it's proving to be a bit of a learning experience. Part of our issue is that the people who originally set it all up (and who started doing the upgrade once upon a time) have moved on to other jobs. Another part is that maintenance of SVN is a very small part of my job - so small it's under other duties as directed in the position description, along with numerous other tasks. (I guess many of us on this mailing list will be in similar positions, too.) I'm still learning, even 25+ years into my work life... Thanks for your patience. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
-Original Message- From: Philip Martin Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes: Here's a log of a trial I have just done with a relatively fresh repository: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testdir Volume in drive C is OSDisk Volume Serial Number is E49F-06D7 Directory of C:\SVN_Test 12/08/2013 09:54 AMDIR . 12/08/2013 09:54 AMDIR .. 12/08/2013 09:54 AM20 test.txt 1 File(s) 20 bytes 2 Dir(s) 160,268,779,520 bytes free C:\SVN_Testcopy test.txt test2.txt 1 file(s) copied. C:\SVN_Testsvn add test2.txt A test2.txt C:\SVN_Testsvn ci test2.txt --message test 1.8.1 checkin Adding test2.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date svn: E175005: File 'test2.txt' already exists I can't reproduce that. Can you look in the apache log files to see the failed request? Can you reproduce the problem over http? Can you provide a network trace? I have emailed Philip and Lieven directly with the network trace file as it's a bit big (600-odd K) for a mailing list. Attached for general amusement and delectation is the relevant portion of our Apache access log for a repeat test I did this morning (Australian Eastern Standard Time). The testing did not touch our Apache error log. Regards, Geoff -- Sorry about the automatic legal disclaimer: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files. ApacheAccess.log Description: ApacheAccess.log
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Friday, 9 August 2013 18:10 PM Geoff Field geoff_fi...@aapl.com.au writes: What about the Commit New Files error? Will this be fixed with 1.8.2, do you think? I don't know how to reproduce it. You said: Second issue: When committing new files, we get the message that one of them 'already exists'. I've found as a workaround that doing a clean checkout to a NEW directory, then copying everything across and running a commit will work - once. but if I were to attempt to reproduce it I would do svnadmin create repo svn co http://localhost/repo wc cp /bin/true wc/foo # error message was for a binary file svn add wc/foo svn ci -mm wc but that works. That's no surprise because what I have done is essentially what you say is a workaround. Until you can come up with a better description of how to reproduce the problem not much can be done. Hello Philip, Sometimes the workaround works, sometimes it doesn't. Here's a log of a trial I have just done with a relatively fresh repository: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testdir Volume in drive C is OSDisk Volume Serial Number is E49F-06D7 Directory of C:\SVN_Test 12/08/2013 09:54 AMDIR . 12/08/2013 09:54 AMDIR .. 12/08/2013 09:54 AM20 test.txt 1 File(s) 20 bytes 2 Dir(s) 160,268,779,520 bytes free C:\SVN_Testcopy test.txt test2.txt 1 file(s) copied. C:\SVN_Testsvn add test2.txt A test2.txt C:\SVN_Testsvn ci test2.txt --message test 1.8.1 checkin Adding test2.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date svn: E175005: File 'test2.txt' already exists C:\SVN_Testsvn --version svn, version 1.8.1 (r1503906) compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme C:\SVN_Test Again, server version is 1.2 (yes, yes, I will update this at some stage in the near future, but apparently I also have to update Apache, which adds an extra layer of nuisance). This was the first time this repository had been touched since 2009. test.txt is a standard ASCII text file containing the sentence A quick test file. with one carriage return. I hope this helps. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Geoff Field Sent: Monday, 12 August 2013 10:20 AM From: Philip Martin Sent: Friday, 9 August 2013 18:10 PM Geoff Field geoff_fi...@aapl.com.au writes: What about the Commit New Files error? Will this be fixed with 1.8.2, do you think? I don't know how to reproduce it. You said: Second issue: When committing new files, we get the message that one of them 'already exists'. I've found as a workaround that doing a clean checkout to a NEW directory, then copying everything across and running a commit will work - once. but if I were to attempt to reproduce it I would do svnadmin create repo svn co http://localhost/repo wc cp /bin/true wc/foo # error message was for a binary file svn add wc/foo svn ci -mm wc but that works. That's no surprise because what I have done is essentially what you say is a workaround. Until you can come up with a better description of how to reproduce the problem not much can be done. Hello Philip, Sometimes the workaround works, sometimes it doesn't. Here's a log of a trial I have just done with a relatively fresh repository: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testdir Volume in drive C is OSDisk Volume Serial Number is E49F-06D7 Directory of C:\SVN_Test 12/08/2013 09:54 AMDIR . 12/08/2013 09:54 AMDIR .. 12/08/2013 09:54 AM20 test.txt 1 File(s) 20 bytes 2 Dir(s) 160,268,779,520 bytes free C:\SVN_Testcopy test.txt test2.txt 1 file(s) copied. C:\SVN_Testsvn add test2.txt A test2.txt C:\SVN_Testsvn ci test2.txt --message test 1.8.1 checkin Adding test2.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date svn: E175005: File 'test2.txt' already exists C:\SVN_Testsvn --version svn, version 1.8.1 (r1503906) compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme C:\SVN_Test Again, server version is 1.2 (yes, yes, I will update this at some stage in the near future, but apparently I also have to update Apache, which adds an extra layer of nuisance). This was the first time this repository had been touched since 2009. test.txt is a standard ASCII text file containing the sentence A quick test file. with one carriage return. I hope this helps. Oh yes, our server is running Windows Serve 2003, Enterprise Edition, SP2. Regards, Geoff -- Apologies for the legal disclaimer auto-inserted by our servers: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Geoff Field Sent: Tuesday, 6 August 2013 9:33 AM From: lieven.govaerts On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin philip.mar...@wandisco.com wrote: Philip Martin philip.mar...@wandisco.com writes: Lieven Govaerts l...@apache.org writes: C:\Customersvn log -v ./ svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software' svn: E27: Additional errors: svn: E27: The requested report is unknown. Geoff, can you log an issue in our issue tracker with reference to this mail thread? http://subversion.tigris.org/issue-tracker.html Done. Issue #4404 has been logged, specifically for the first part of the issue. Personally, I don't like reporting two issues in one report, so I'll leave the other issue separate - at least until I'm asked to lodge that as well. At least the original issue report references some of the many mailing list discussions about it. So does the patch fix both issues? ... That's easy to reproduce using 1.1.4 mod_dav_svn: ... Can you test if attached patch fixes this issue? What about the Commit New Files error? Will this be fixed with 1.8.2, do you think? Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
SVN 1.8.1 Errors - Show Log and Commit New Files
I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its command-line basis. Our server has been running 1.2 and has not been changed (apart from Windows updates) for a LONG time. (Yes, I know 1.2 is very old. However, we're an automotive company and changes to our tools can result in issues with customer approvals. Nonetheless, an upgrade is on the to-do list.) Having said that, there are now MANY people posting to the TSVN mailing list about these two issues. My platforms are 32-bit Windows 7 and Windows XP, but it has also been reported on 64-bit Windows. First issue: When doing a Show Log, the client says it can't contact the server and asks if people (including us) want to go offline, then puts up an HTTP 501 error. Second issue: When committing new files, we get the message that one of them 'already exists'. I've found as a workaround that doing a clean checkout to a NEW directory, then copying everything across and running a commit will work - once. After discussions on the TSVN mailing list, I've run command-line versions of both, with the following results (edited to hide customer names): C:\Customersvn log -v ./ svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software' svn: E27: Additional errors: svn: E27: The requested report is unknown. C:\Customersvn commit ./ -m Committing via command line Adding (bin) DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr lLimits.xlsx' is out of date svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists C:\Customersvn --version svn, version 1.8.1 (r1503906) compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Regards, Geoff -- Geoff Field - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
From: lieven.govaerts On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin philip.mar...@wandisco.com wrote: Philip Martin philip.mar...@wandisco.com writes: Lieven Govaerts l...@apache.org writes: C:\Customersvn log -v ./ svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software' svn: E27: Additional errors: svn: E27: The requested report is unknown. Geoff, can you log an issue in our issue tracker with reference to this mail thread? http://subversion.tigris.org/issue-tracker.html Done. Issue #4404 has been logged, specifically for the first part of the issue. Personally, I don't like reporting two issues in one report, so I'll leave the other issue separate - at least until I'm asked to lodge that as well. At least the original issue report references some of the many mailing list discussions about it. For this part of your issue, I'm interested in seeing a network trace (wireshark, fiddler) between your client and server. Thanks Philip. ... That's easy to reproduce using 1.1.4 mod_dav_svn: ... Can you test if attached patch fixes this issue? And thanks for that Philip and Lieven. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
