"Offset too large" error when packing repository in FSFS 7 format
Hello. Today, I encountered a problem when trying to pack a repository after migrating it to the FSFS 7 format by performing full dump / load sequence. Shortly, I get the following error “Packing revisions in shard 5...svnadmin: E160056: Offset 391658998 too large in revision 5102” I was not able to understand from the documentation, what settings in fsfs.conf should be modified to workaround this problem. Neither search in the Internet brought any light into this. Is it even possible? The mentioned revision seems to be a result of an user error. It resulted in adding 169,200 paths to the repository. The delta file of the revision 5102 is 394141477 B. Subversion 1.9.3 was used when performing this operation on CentOS 7.2. FSFS 7 backed uses default configuration (therefore deltification is used). Originally, the repository was stored in FSFS 6 format with default settings (no deltification). Packing the repository in old format finished successfully and the pack file size was about 831 MB. Looking forward to hearing any guidance how to configure my backend so that I can eventually pack the repository in the new format. Thanks, Radek Krotil
suggestion: enhance workspace locking/clean message
Hi, At the moment users get a "workspace is locked, please run clean" style message if they run two subversion commands on the same workspace. Obviously the solution is to "not do that", but for example with subversion integrated into tools it may not be obvious to a user. I had several users corrupt a workspace by running a clean against a running command. My suggestions: Store a process identifier together with whatever is used to lock a workspace, send a "ping" style message to the active process when another command is run. If the other command is still running change the report to "another process is still accessing the workspace" Optionally block the second process until the first process is complete. actually I was thinking about implementing that in our tools by peeking into the workspace lock data, but didn't have time so far. Cheers, Jens
Re: suggestion: enhance workspace locking/clean message
On 03.06.2016 16:05, Jens Christian Restemeier wrote: > > Hi, > > At the moment users get a “workspace is locked, please run clean” > style message if they run two subversion commands on the same > workspace. Obviously the solution is to “not do that”, but for example > with subversion integrated into tools it may not be obvious to a user. > I had several users corrupt a workspace by running a clean against a > running command. > > > > My suggestions: > > Store a process identifier together with whatever is used to lock a > workspace, send a “ping” style message to the active process when > another command is run. If the other command is still running change > the report to “another process is still accessing the workspace” > > Optionally block the second process until the first process is > complete… actually I was thinking about implementing that in our tools > by peeking into the workspace lock data, but didn’t have time so far. > Which version of Subversion are you using? In general it is safe to run multiple Subversion commands simultaneously on the same working copy; access to the working copy database is transactional and protected by the global database lock. If that's not good enough for you, you can enforce exclusive locking of the working copy and only one client at a time will be able to access the working copy; see: http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking -- Brane
RE: SVN
Everyone, Thank you very much for your guidance and the wealth of knowledge you have provided. I'll make the recommendation not to squeeze everything into SVN. Thanks, Perry -Original Message- From: Eric Johnson [mailto:e...@tibco.com] Sent: Friday, May 27, 2016 4:44 PM To: Joseph Bruni; PERRY JENNINGS Cc: users@subversion.apache.org Subject: Re: SVN On 5/27/16 12:57 PM, Joseph Bruni wrote: > > On May 26, 2016, at 10:09 PM, PERRY JENNINGS > wrote: > >> Family Dollar has implemented SVN and about sixty percent of projects >> within the organization currently uses this repository to maintain >> source code for object-oriented applications. However, the remaining >> forty percent of source code within the organization cannot use SVN >> because the code is for *non-object-oriented* applications ; >> Terminology is confusing me here. Object-oriented code has nothing to do with version control. Is what you really mean that you work with tools that deal with either monolithic project files, or smaller but opaque binary files? >> >> hence a single file, not a project needs to be checked in and out of >> the repository. So my question is: Are you aware of a client that >> could be used to checkout and checkin a single file to the SVN >> repository and maintain the version number of the source code that is >> checked in? If not, do you know if SVN has the single file checkout >> and checkin feature? >> As a previous poster has mentioned, Subversion has "lock" functionality, so you can signal to people that changes are pending. > > We do the same thing for the database SQL scripts, stored procedure > code, and various one-off Perl programs. Source control systems like > SVN (or Git) don't really lend themselves directly to this type of object. Why would you say that? I've used Subversion for all of the above. Works great. I'd be curious what issues you've run into? > We do use SVN, but layered a lot of process on top of it to keep > ourselves somewhat sane. That's true of any source control system. You still need to manage the people and the workflows. Version control tools just make it easier to manage the shared built artifacts. > > I can imagine someone could build a nice single-file revision control > system on top of SVN, but it would require a new type of client that > would hide the directory revisioning from the user. An alternate tool like Perforce can be used, as I recall, to actively prevent people from making changes to a file when it isn't "checked out". This is otherwise known as "pessimistic locking." If your user needs require pessimistic locking, then you should use a tool that does it. Probably not a good idea to squeeze everything into Subversion, if that's the case. Eric. -- NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: SVN hangs/locking issue?
Hi Chris,
On 6/2/2016 18:41, Chris Mirabito wrote:
> Hello everyone,
>
> Our group has SVN installed on our computing cluster, but we have
> recently been having trouble with it not working and/or hanging.
> I have pasted the output we get from "svnadmin verify". These errors
> occur for multiple users on our system, independent of the specific
> repository we are trying to access.
What errors are you referring to exactly. Reading the attached log file,
I assume you are referring to this error, no?
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824,
len=1}) = -1 ENOLCK (No locks available)
If so, googling for that brings up a couple of things to check out [1]:
- check whether the disc is full
- check whether the user account you are running from has the necessary
permissions to write to the svn directory
- non-running lock daemon on the NFS server
Hope this hints you to the right direction to find out what's wrong there.
Regards,
Stefan
[1] http://serverfault.com/questions/61594/what-does-no-locks-available-mean
smime.p7s
Description: S/MIME Cryptographic Signature
Re: svn: E155008issue with subversion in webmethods designer
Hi Pavel, On 6/1/2016 18:04, Pavel Lyalyakin wrote: > Hello Stefan, > > On Sun, May 29, 2016 at 11:03 PM, Stefan wrote: >> I'm not 100% sure, but this might be related to issue #4364, which is fixed >> in SVN 1.8.8: >> lock of deleted pathes magically reappear when pathes are reused >> >> In this case upgrading to a later SVN version should resolve the issue. >> >> Alternatively the issue at question might also be #2507 which is not yet >> resolved: >> 'commit --no-unlock' doesn't remove locks on files deleted >> >> In this case the workaround might be to ensure in the tools to not use the >> --no-unlock flag and/or to ensure that for deleted files the lock is removed >> first via svn unlock. > How did you determine that this is #4364 or #2507? thanks for asking and sorry for the late response (quite some busy days at work and in private, so I just got to reply right now). Well, I came to that idea because of the given error message: "[...] error running command [svn, unlock [...] svn: E155008: The node 'C:\SoftwareAG\IntegrationServer\packages\testsvn\ns\new_folder22\new_flowservice1' is not a file" At the time of replying there I was wondering why svn would try to unlock new_flowservice1 which, taken from the error message, didn't seem to be a file (but presumably a folder). Only after reading your reply I got the idea that I incorrectly assumed the unlock call was some implicit action from some svn-API call where svn would try to perform an invalid unlock rather than some explicit svn command line call from the 3rd party tool/script. Anyway, to answer your question: The fact that Divvela stated that the external vendor they contacted said it's an issue in Subversion, I assumed the vendor was aware of a known bug in Subversion and I tried to find out which one they might refer to (aka: whether an upgrade to a later version would help the user or whether there's a workaround for an unresolved issue). Searching SVN's issue tracker for "unlock" and issues not yet resolved (or resolved after 1.7.9) brought up these two candidates for me. SVN-4364 is reported to affect 1.7.x and was fixed in 1.8.8. Therefore the version range would match. The comments depict a repro case of a locked file being removed and the lock not being dropped from the db. After recreating a file with the same path, the new file was locked. It's stated that the corresponding entry in the sqlite db didn't get the lock entry removed. So I assumed it could also be a possible variation to end up with a lock entry in the db on a directory, if instead of creating a file on that path, one would create a directory and that could then trigger SVN to try to unlock the directory (aka: this was due to my false assumption of an implicit rather than an explicit unlock action - see above). For SVN-2507 my thinking was that if a commit was done with the --no-unlock option it would also lead to the dangling lock entry in the sqlite db. Again, assuming that creating a folder with the same name afterwards would then result in a folder with an associated lock entry in the db, that sounded like a possible cause of the reported error and therefore another candidate of what that 3rd-party vendor might have been referring to (again: all under the same wrong explicit/implicit unlock assumption). > To me it looks like webmethods is calling some Subversion client and it > is trying to perform `svn unlock` operation on a folder. Looks like > the error it totally expected in such case. Sounds absolutely right to me, now that I get that's most likely some explicit svn unlock command call the other tool is doing. > > Without some additional description of the case it's impossible to > tell what's going on. Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
