Tree conflict: Add/Add on directory
Hi, I'm having trouble resolving a tree conflict. I'm working on a feature branch, and I regularly merge from trunk to the branch. In my latest merge, I got a tree conflict because a directory (playback) has been added both to trunk and to my branch, with different contents. I want to get rid of my version and use the one from trunk. This should be trivial, but it isn't: $ svn resolve --accept theirs-full playback svn: warning: Tree conflicts can only be resolved to 'working' state; 'playback' not resolved So I thought I'd delete the directory and use svn cp to copy the branch version into my working copy. The delete worked: $ svn st --depth=empty playback D C playback local add, incoming add upon merge And I can easily get the URL I need to copy from: $ svn info playback URL: http://svnserver/repos/branches/feature/wherever/playback ... Tree conflict: local add, incoming add upon merge Source left: (dir) http://svnserver/repos/trunk/wherever/playback@2373 Source right: (dir) http://svnserver/repos/trunk/wherever/playback@3515 But the copy doesn't work: $ svn cp http://svnserver/repos/trunk/wherever/playback@3515 . svn: Path 'playback' already exists (I also tried svn cp http://svnserver/repos/trunk/wherever/playback@3515 playback, but that put it in the wrong place (playback/playback/ rather than just playback/) and seemed to get my working copy in a bugged state, requiring non-SVN rm and svn cleanup to get it working again). I guess I could split the commit into two - if I did a first commit for the rest of the merge and to delete the playback directory, I'd probably be able to use svn cp and do a second commit to re-add it with the right contents. This seems like a very ugly hack. Any ideas how to resolve this properly? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Revisions not in chronological order
Giulio Troccoli wrote: From: Chris Evans [mailto:chris.ev...@gresearch.co.uk] My repository is made up of a load of folder loaded from cvs2svn dumps. These were loaded individually and have overlapping date ranges. When doing an svn load it looks like SVN assigns each commit to the next revision, regardless of the date the commit occurred. As a result the rage of revisions created for each of the loads have overlapping dates and the revisions of the repository are not chronological. This is expected behaviour if have loaded two or more dumps into the same repository. I seem to remember there is a tool out there to merge dumps file, but I don't remember the name. I don't even know if it would merge them in chronological order or not. Google it and see what you can find. http://svn.borg.ch/svndumptool/ Haven't tried it myself, but it claims to do what you want. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SVN Keywords...
http://subversion.apache.org/faq.html#version-value-in-source Kind regards, Jon -Original Message- From: BRM [mailto:bm_witn...@yahoo.com] Sent: 26 October 2010 20:56 To: SubVersion Users Subject: SVN Keywords... I have a series of projects that operate as service daemons; all the projects have a simple main.cpp that loads another class that does the actual work. So I never have to touch main.cpp except when I go to make a release, and then only to update a couple things: version numbers and dates. I'd like to try to automate the data modifications a little bit more; and while SVN has the $Date$ keyword, aka $LastChangedDate$; that's not quite correct for what I want to do - svn after, all svn won't detect a change if there are no actual modifications on the file (e.g. touch somefile.cpp won't result in a delta in svn), at least as explained in the svn red book[1]. Would it be possible to have a $LastCommitDate$, and perhaps a $LastCommitRevision$ that is not file specific but name space specific, since SVN operates on name spaces (e.g. ^/some/svn/path) instead of files ( ^/some/svn/path/some.file.with.extension)? Or perhaps $LastUrlCommit...$. In either case the specified name space should likely be the URL/namespace where the file is located, perhaps with an option to have the base URL when it was checked out/exported. This could be provided using arrays, for example $LastCommitDate[0]$ could be the base URL while $LastCommitDate[1]$ is the URL of the file. For the svn:externals use-case, the URL would be related to the external, not to the project pulling the URL in. So suppose the following: Project located at /myproject/trunk, pulls in an svn:external from /myotherproject/tags as lib1; the proposed keyword set would apply to /myproject/trunk only for files that actually exist in the repository under that URL, while the proposed keywords for the files checked out/exported to lib1, which are located under /myotherproject/tags, would apply the URL of the external - /myotherproject/tags and not /myproject/trunk. While I understand the logic present in the $GlobaRevision$ section on in the SVN Redbook[1], there is also some problems with the suggested resolution when trying to do the same thing on multiple platforms, namely and especially MS Windows where processing of 'svnversion' output is impossible with standard tools on the platform to say the least. Ben [1]http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.key words.html __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Path based authorization
Hi, Robert Johnson wrote: I'm not sure this is a bug or the documentation is wrong, or I'm misunderstanding the concept. In the SVN doc: Section 6.5 Path-Based Authorization [paint:/projects/paint] jane = r @paint-developers = rw Another important fact is that the first matching rule is the one which gets applied to a user. In the prior example, even though Jane is a member of the paint-developers group (which has read/write access), the jane = r rule will be discovered and matched before the group rule, thus denying Jane write access. Older versions of the SVN book were wrong. The latest version has corrected this. See: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h tml Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How do I enforce a minimum client version when hosted via httpd
Hi, Stephen Connolly wrote: I remember reading before about a hack/trick that allows you to ensure that the client is at least mergeinfo aware when the repository is served via Apache httpd. You can have a start-commit hook. It can reject commits from clients that don't have the mergeinfo capability. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html A better trick would allow blocking clients less than 1.6.13 from connecting ;-) Subversion sends it's version in the User-Agent string. You can test that in your Apache config file. (But this is probably a bad idea unless it's an internal SVN server that's locked down by corporate policy). http://httpd.apache.org/docs/2.2/howto/access.html#env Bear in mind that some people may not be using the official Subversion client. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Fwd: Repository Directory Tree
Stefan Sperling wrote: On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: I send this email out about once a month or so in what is becoming the vain hope I'll get a response... My subversion repository is in /var/svn. Somehow (and, yes, I'm new; I'm evaluating it), I've wound up with the following directory structure in my subversion repository: /var/svn/ var/svn/proj1 var/svn/proj2 var/svn/proj3. [snip] I've tried to do an svnadmin dump and load with --parent-dir, and that didn't work. This was the command line sequence after I had made a copy of the repository in /var/svn.sav: svnadmin dump /var/svn.sav old_repos rm -r/var/svn/* svnadmin create /var/svn svnadmin load --parent-dir / /var/svn old_repos But, even though I had parent-dir as / (to try to eliminate one of the /var/svn's), I still got /var/svn/var/svn/projects. What is the way to do this? You want to remove the leading /var/svn components from all paths in the dump file. See here: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html #svn.reposadmin.maint.filtering The part that starts with: At this point, you have to make a decision. Each of your dump files will create a valid repository, but will preserve the paths exactly as they were in the original repository. is the interesting part you should read especially carefully. Stefan I'm wondering if svndumptool could do this automatically. (Maybe 'svndumptool merge -o out.dump -i in.dump -r var/svn/proj1 proj1' ?) But I haven't tried it. See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is this a bug ?
Hans wrote: I got no reaction on freenode#svn, so here goes : This looks like a bug in 1.6.12 to me : for a subdirectory with its .svn/ removed a 'svn up --force .' in its parent does not recreate it where 'svn up --force dirname' does That won't happen in Subversion 1.7, so I wouldn't worry about it. (Subversion 1.7 won't have .svn folders in subdirectories, so you won't be able to delete them). Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is 'svn lock' possible for replication?
Hi, Steven Woody wrote: On 20 August 2010 23:19, Steven Woody narkewo...@gmail.com wrote: Hi, With a replication/write-through setup, can a user execute 'svn lock' on master/slaver nodes? Thanks. Hey folks, no one can gives me a hint? The SVN Book answers your question. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
Daniel Shahaf wrote: Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 15:27:25 -0500: Ramkumar: Again, I expect that access control/ security is automatically taken care of in the RA layer. `svnrdump load` is just like a user making some changes and committing them one by one except the author and timestamp in the dumpfile are preserved. Why would you want to block this? A client performing a regular commit cannot currently spoof the author and timestamp, or can they? Yes: svn propset --revprop svn:author svn propset --revprop svn:date But not by default. Changing revprops has to be explicitly enabled by the repository administrator. To do this, the server admin has to explicitly create a pre-revprop-change hook, and set it to allow the changes. Many pre-revprop-change scripts will disallow changes to svn:date and svn:author, although they might allow other revprops such as svn:log to be edited. http://svnbook.red-bean.com/nightly/en/svn.ref.reposhooks.pre-revprop-ch ange.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Steven Woody wrote: Thanks everyone, and, can I get know if the replication/write-through things support https? Yes, they do. The master that I want to mirror is using https On the mirror, you need the appropriate Apache modules and configuration. Make sure you have mod_proxy and mod_ssl loaded as well as the normal Subversion modules. The proxy-specific config I've used is: VirtualHost ... ... SSLProxyEngine on SSLProxyCACertificateFile /some/local/path/master_cert.pem SSLProxyVerify require SSLProxyVerifyDepth 10 Location /svn ... standard SVN config omitted ... SVNMasterURI https://masterserver.mysite.example/svn /Location /VirtualHost The path /some/local/path/master_cert.pem should contain the SSL certificate for your master SVN server. To create it, I just browsed to the master SVN server using a web browser and saved the SSL certificate to a file. (In Firefox: Navigate to SSL page, click padlock in bottom-right corner of browser, View Certificate, Details, Export). Useful reference: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Migrating from 32 to 64 bit
Hi, SVN decides if two repositories are the same by comparing their UUIDs. You can get the Repository UUID from the old repository with svn info, and set it on the new repository with svnadmin setuuid. Kind regards, Jon From: Leszek Szarlej [mailto:leszek.szar...@gmail.com] Sent: 11 August 2010 18:56 To: Edward Ned Harvey; Leszek Szarlej; users@subversion.apache.org Subject: Re: Migrating from 32 to 64 bit Thank you for your answers. Currently I've setup svnsync and I am doing test run of synchronizing repositories. I will have a small window to migrate repositories. Using the svnsync gives me possibility to do major job before the change window and then final sync during the change. In this step I have some doubts whether users will have possibility to relocate their local copies to new repository on new server. The first step of sync procedure is to create fresh repository, I am afraid that it will have different ID and svn will say its not the same repository I will test it but you are welcome to give me your comments. I have about 400 repositories to migrate. Svnsync showed about 60 -70 hours to sync all repos. Thanks much Leszek Szarlej On 11 August 2010 15:50, Stefan Sperling s...@elego.de wrote: On Wed, Aug 11, 2010 at 09:11:29AM -0400, Edward Ned Harvey wrote: As far as subversion is concerned, as long as you get it installed, there is nothing for you to think or care about. It depends on the Subversion repository backend. If the BerkeleyDB backend is used, a dump/load cycle is probably necessery, so just do it to be on the safe side. With repositories using FSFS, there is nothing to worry about. The file db/fs-type in a repository tells you which kind of backend the repository is using: bdb or fsfs Stefan __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Ulrich Eckhardt wrote: On Wednesday 11 August 2010, Ryan Schmidt wrote: you can set up a write-through proxy so that people who check out from a slave and try to commit will be transparently redirected to the master. How? It's described in the book: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.s erverconfig.httpd.extra.writethruproxy Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Merging repositories - is it possible?
Hi, Les Mikesell wrote: On 8/6/2010 10:12 AM, Itamar O wrote: On Fri, Aug 6, 2010 at 4:56 PM, JWalker jwal...@hotmail.bg This is my first post here. Is it possible to merge several repositories in a new empty repository? I am asking this, because I made several repositories of one project, one repository for mechanics, another for the software, another one for the electronics and so on. Now I see that this will be a bit hardly to maintain when more projects appear in the future. My goal is to create this layout (example) / /mechanics /software /electronics and then load the repository of mechanics to /mechanics, the repository of software to /software and so on. So, is this scenario possible - by bump/load procedure or something else? This is exactly the use case described in the SVN redbook: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html #svn.reposadmin.maint.migrate But note that although the revision histories are maintained, when you combine them the revisions will be renumbered and you also won't be able to specify date ranges because the changes will be out of order in the combined repository. If you care about that, you could try svndumptool merge. See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Subversion 1.6 write-through proxy mirroring
Jim Lord wrote: I'm setting up a write-through proxy mirror. I can run: svnsync init --source-username svnsystem --source-password $pass --sync-username svnsystem --sync-password $pass file:///data/svn/vtest https://versiontest2.divxnetworks.com/svn/vtest from the slave machine versiontest1 BUT, I can't run: svnsync init --source-username svnsystem --source-password $pass --sync-username svnsystem --sync-password $pass https://versiontest1.divxnetworks.com/svn/vtest file:///data/svn on the master without getting the error: svnsync: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent The pre-revprop-change hooks exist on both master and slave for the vtest repository What are the filesystem permissions on your pre-revprop-change hook in the target repository? What user does Apache run as? Does that user have execute permission on the hook script? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Debian svn + apache2 configuration errors
Hi, kevin fauchon [mailto:kevin.fauc...@gmail.com] wrote: AuthzSVNAccessFile /DATA/svn/config [...] /DATA/svn/conf: [/] * = anonymous = r You need $anonymous here - you're missing the $. So you granted read access to a user that's logged in with the username anonymous, not to anonymous users. (But I'm not sure why you don't just do *=r - any of your users could get read access by simply logging out). [test:/] test = rw [...] And when i try to go to http://svn.monpoulpe.com/test i have a 403 forbiedden error On a related point... I have a Python script that does lint like checks on Subversion AuthZ files. It would have detected this bug, since it reads the .htpasswd file and would have reported that you're granting permissions to a non-existant user. Would the Subversion developers be interested in including it in Subversion? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: can't build with zlib
Hi, Edward Ned Harvey wrote: I have tried everything I can think of, and I can't seem to get svn to build with the zlib that comes with it. It's always linking against /usr/lib64/zlib. After build: ldd `which svn` | grep libz libz.so.1 = /usr/lib64/libz.so.1 (0x0034a690) What's the full output of ldd? Are you linking against some other library that's linked against your system zlib? Run ldd on every other library that's listed, to see if any depend on libz.so. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: JavaHL - when using peg makes the difference in diffSummarize()
Hi, m g wrote: Subject: JavaHL - when using peg makes the difference in diffSummarize() can you provide me at least one case in which passing a non-null peg revision to SVNClientInterface.diffSummarize() returns a different result than when passing null ? Thanks Mário Have you read the SVN book? http://svnbook.red-bean.com/ It has a good explanation of peg revisions. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: cannot break lock due to no matching lock-token
Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use svn unlock --force. See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: cannot break lock due to no matching lock-token
Hi, could I use a local command line client (while keeping Tortoise resident) to execute this? Yes. The command line client can be downloaded from here: http://subversion.apache.org/packages.html#windows I use the SlikSVN one, but it really doesn't matter which one you use. Kind regards, Jon -- Please direct all replies to the mailing list. -Original Message- From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:47 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Thanks for replying. I am using TortoiseSVN, which directs me to this mailing list for discussion. Pardon my amateurishness, could I use a local command line client (while keeping Tortoise resident) to execute this? -Original Message- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, April 14, 2010 7:23 AM To: Tom Jones; users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use svn unlock --force. See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ *** The information in this e-mail is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this e-mail in error please notify the sender by return e-mail delete this e-mail and refrain from any disclosure or action based on the information. *** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England
RE: Multiple Lines for groups in authz conf file
Hi, I'm using mod_authz to specify permissions in svn. Is there a way to list the group members on multiple lines instead of just a single line? For example, instead of: [groups] developers=joe, frank, bob I would like to have something like: [groups] developers= joe, frank, bob Will this work? The reason is that one of the groups is very large, and it's messy to have all the users on one line. In Subversion's configuration files, leading whitespace indicates a continuation line. So you could do: [groups] developers = joe, frank, bob Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: merging repositories
Hi,
Tobias wrote:
I have a project with two different repositories,
that I want to merge into one common repository.
Would svndumptool merge do what you want?
http://svn.borg.ch/svndumptool/
(I haven't tried it, it's just something I found and
bookmarked when investigating Subversion)
The simplest way would surely be to say:
$ svnadmin dump Base/ base.dmp
$ svnadmin dump Develop/ develop.dmp
$ svnadmin load --parent-dir Base/ Merged/ base.dmp
$ svnadmin load --parent-dir Develop/ Merged/ develop.dmp
However, this does not semantically respect the correct time order
[...]
Will svnadmin load keep the commit dates
Yes. They're just a revision property.
and if so, what would be the outcome of, say,
svn update -r {someDate}?)
Undefined (and unpredictable). My understanding is that this
does a binary search, which will go haywire if your dates
aren't monotonically increasing. So you can't use it on
such repositories.
Kind regards,
Jon
--
(Please direct all replies to the mailing list)
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: SVN respository expiry date
Hi, Arthur Chan wrote: I am requesting SVN checkin time from my previous company. ... However, they told me that SVN only store logs for 3 months by default so that all my commit time were lost. There are 2 different places you can get commit time information. First, there are the logs from Subversion. These are reliable (no-one apart from the system administrator could forge them). They are optional - you don't have to generate them. If you do generate them, then it's up to you to decide how long to store them for. They can log all activity, including commits, checkouts, and updates. I suspect the logs are what your company is talking about, and it's quite plausible for them to be stored for only 3 months. Secondly, there is the svn:date revision property in the repository. These may or may not be reliable, depending on whether your repository has a pre-revprop-change hook that allows them to be changed. (By default, they cannot be forged by anyone other than the system administrator. But if your system administrator installs a pre-revprop-change hook that allows it, then any committer can change them to any value, without leaving an audit trail). They are generated automatically by Subversion, you can't (easily) turn them off. Subversion will store them forever (or until someone changes or deletes them). These only tell you the commit time, they won't tell you about checkouts or updates. Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: 403 Forbidden in response to COPY request
Hi, Anton Prowse wrote: [...] [/trunk/specialfile] user2 = [...] when I authenticate as user2 I receive the following error when trying to create a branch from the trunk of repos1: Server sent unexpected return value (403 Forbidden) in response to COPY request for '/repos/repos1/!svn/bc/999/trunk' user2 is trying to copy /trunk/specialfile to somewhere where he'd be able to read it. So Subversion blocks it. In order to create a branch from trunk, you need read access to trunk and every file inside it. Perhaps /trunk/specialfile can be moved somewhere else, so you can remove this restrictive permission? (This may require you to dump the repository and use svndumpfilter to get rid of the historical revisions of /trunk/specialfile). Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: svn log via svnserve is letting me see things it shouldn't, but svn ls works as I expect
Hi, Stefan Sperling wrote: On Wed, Mar 03, 2010 at 03:01:22PM -0600, Reid Priedhorsky wrote: In particular, log messages to files not in /cyclingproject/public should not be available. Log message are not per file. They are per revision. They aren't tied to any particular path. Off-hand I cannot think of a way to prevent them from being seen. But the documentation for how authz works says: http://svn.apache.org/viewvc/subversion/trunk/notes/authz_policy.txt?ann otate=859714 == WHAT USERS SHOULD EXPECT FROM PATH-BASED AUTHZ == [...] 2. LOG MESSAGES Log information may be restricted, based on readability of changed-paths. * If the target of 'svn log' wanders into unreadable territory, then log output will simply stop at the last readable revision. If the log is tracing backwards through time, as the plain svn log command does, the target will appear to be added (without history) in that revision. * If a revision returned by 'svn log' contains a mixture of readable/unreadable changed-paths, then the log message is suppressed, along with the unreadable changed-paths. Only the revision number, author, date, and readable paths are displayed. * If a revision returned by 'svn log' contains only unreadable changed-paths, then only the revision number is displayed. Is this documentation wrong? Or doesn't it apply for some reason? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org
Hi, Pete Hatton wrote: Anyone know the unsubscribe information for the old list? I don't know the official procedure, but here's what I did: 1) Go to http://subversion.tigris.org/ 2) Log in using the Login link at the top right corner of the page. (The login page has a Forgot your password link that will allow you to set a new password, if you forgot your old one). 3) Go to the old Users mailing list page. The links seem to have vanished from the Subversion web site, but I fould it via Google: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=1065 4) Click the link that says My subscription settings 5) Untick the box that says Subscribed and click the Save Changes button. 6) If you're also subscribed to the dev list, go to this URL: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=462 Then repeat steps 4 and 5. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Where is the latest SVN 1.6.9 binary for stable debian?
Hi, Pat Farrell wrote: My debian server is running Lenny, the latest and greatest debian. The svn version is svn, version 1.5.1 (r32289) I'd like to be running 1.6.9 I can't find the .deb files, or better, a good repository to add to my /etc/apt sources.list. 1.6.4 is available in the backports.org repository: http://www.backports.org/dokuwiki/doku.php?id=instructions http://packages.debian.org/lenny-backports/subversion But they don't have a 1.6.9 package yet. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug - corrupted proxy repo
Hi, I am assuming that if the commits must start at least one second apart - then the sync from the post-commit hook would not be able to reach a race condition. Is this a reasonable assumption? No, the bug is worse than that. Suppose there are 3 commits: - At time 12:00:00, a commit starts sync process #1. The sync takes 6 seconds. - At time 12:00:02, a commit starts sync process #2. This blocks due to sync process #1's lock. - At time 12:00:04, a commit starts sync process #3. This blocks due to sync process #1's lock. - At time 12:00:06, sync process #1 finishes. Sync processes #2 and #3 both try to take the lock; due to the bug they may _both_ succeed in taking the lock. Chaos ensues. I suggest you use the flock(1) tool. [1]. This is installed as a standard part of Debian (it's in the util-linux package). Something like this, in your post-commit hook: --- cut here - start --- #!/bin/sh /usr/bin/flock --wait 1200 \ -x /var/lock/svn_sync_lock \ /usr/local/bin/svnsync sync --non-interactive \ http://mirrorserver.example.com/svn --- cut here - end --- You will need to make the /var/lock/svn_sync_lock file and ensure it's writable by the user your post-commit hook is running as. flock is a mature, tested piece of code to handle locking. It will ensure that only one copy of svnsync is running at a time. That way, the race condition in svnsync is avoided. Kind regards, Jon [1] http://www.google.co.uk/search?q=man+flock%281%29 -Original Message- From: Andersen, Krista [mailto:krista.ander...@itg.com] Sent: 15 January 2010 22:29 To: Jon Foster; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug - corrupted proxy repo Thank you Jon, for your explanation and workaround. Are there any best practices that we can advise our dev groups to follow to avoid this problem? Otherwise, your suggestions seem to indicate I would have to run the sync on a cronjob and not with the hook script. That is something we would like to avoid. So I have added a start time comparison and sleep in a start-commit hook instead. Do you see any reason why this would cause other problems? I am assuming that if the commits must start at least one second apart - then the sync from the post-commit hook would not be able to reach a race condition. Is this a reasonable assumption? #!/usr/bin/sh # START-COMMIT HOOK # kanderse Jan 13, 2010 # The start-commit hook is invoked before a Subversion txn is created # in the process of doing a commit. # This script checks the start time and compares with the start time # of the previous commit. It will cause a commit to wait one second if # the last commit was started less than one second earlier. # The purpose of this wait is to prevent known issue 3546 [1][2]. # a race condition involving multiple sync processes running at # the same time that result in a corrupted proxy. REPOS=$1 USER=$2 DATE1=`cat /$REPOS/hooks/start-time.txt` # previous start time DATE2=`/usr/local/bin/date +%s` # record current start time echo $DATE2 /$REPOS/hooks/start-time.txt # echo $DATE2 $DATE1 `expr $DATE2 - $DATE1` if [ `expr $DATE2 - $DATE1` -lt 1 ] then sleep 1 # to prevent sync race that results in sync duplication and corrupted proxy fi # All checks passed, so allow the commit. exit 0 Krista Andersen Global Development Infrastructure Investment Technology Group, Inc. 400 Corporate Pointe, 8th Floor Culver City, CA 90230 Direct: 213.270.7570 -Original Message- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, January 13, 2010 5:13 AM To: Andersen, Krista; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug - corrupted proxy repo Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: Twice I have seen one of my proxy repositories become corrupted due to an apparent bug in the svnsync sync process. Has anyone else seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. Here is a comparison the output of the svn log -v for the offending revisions (324,325) on both the corrupted and non-corrupted proxy repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). I am a bit concerned about the stability of Subversion since this is the second time in two months that I have had to fix this issue. Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook scripts to use the lockf or lockfile tools[3] to ensure that only one instance of svnsync runs at once. Kind regards, Jon [1] http://mail
RE: sync bug - corrupted proxy repo
Hi, Ryan Schmidt wrote: But Subversion blocks the commit until the post-commit is done. That particular SVN client will be blocked. But if you have two users committing at the same time, or if a user runs svn twice in parallel, then the post-commit hook will be run in parallel. Here's how I tested this. I created a new repository with a post-commit hook that takes 30 seconds to run. I then checked that it works, and that a normal commit took 30 seconds. I then did two commits in parallel, and that took 30 seconds. This shows that the post-commit hook is running in parallel - if it had been run in series, then it would have taken 60 seconds for 2 commits. (I also checked the output of ps and observed the two post-commit processes running). ~$ mkdir svnscratch ~$ cd svnscratch/ ~/svnscratch$ svn --version | head -n1 svn, version 1.6.8 (dev build) ~/svnscratch$ svnadmin create repo ~/svnscratch$ cat repo/hooks/post-commit #! /bin/bash sleep 30 ~/svnscratch$ chmod a+x repo/hooks/post-commit ~/svnscratch$ time repo/hooks/post-commit real0m30.004s user0m0.000s sys 0m0.008s ~/svnscratch$ time svn mkdir -m Test file://`pwd`/repo/trunk Committed revision 1. real0m30.030s user0m0.008s sys 0m0.008s ~/svnscratch$ time ( svn mkdir -m Test file://`pwd`/repo/branches svn mkdir -m Test file://`pwd`/repo/tags ) Committed revision 2. Committed revision 3. real0m30.069s user0m0.004s sys 0m0.020s ~/svnscratch$ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug - corrupted proxy repo
Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: Twice I have seen one of my proxy repositories become corrupted due to an apparent bug in the svnsync sync process. Has anyone else seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. Here is a comparison the output of the svn log -v for the offending revisions (324,325) on both the corrupted and non-corrupted proxy repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). I am a bit concerned about the stability of Subversion since this is the second time in two months that I have had to fix this issue. Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook scripts to use the lockf or lockfile tools[3] to ensure that only one instance of svnsync runs at once. Kind regards, Jon [1] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127115356.gc9...@jack.stsp.name%3e [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3546 [3] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127132659.ge9...@jack.stsp.name%3e ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: malformed file problem -- version 1.5.7
Hi, James D. Parra [mailto:jam...@musicreports.com] wrote: Is there a way that I can repair this? No idea, sorry. But: Is there a way to roll back to revision 11529 and start there? Try svnadmin dump with the -r parameter to dump just the revisions you want to keep, then svnadmin load to load them into a new repository. Any checkouts of r11529 or earlier should be OK; if you have a later checkout then you'll need to delete it and re-checkout. Should I remove all the revision number files greater that 11529 Hand-editing the repository sounds like a bad idea*... you might get rid of this corruption but introduce a different corruption. Using dump/load should give you a valid repository. Kind regards, Jon [*] It's number zero on the Subversion Worst Practices guide: http://www.red-bean.com/fitz/presentations/2007-07-27-OSCON-svn-worst-pr actices.pdf ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
