Strange error in HPUX 1.6.16 SVN client
We tried installing a SVN 1.6.16 client on a HPUX platform. We had to install some packages missing for /dev/random and also a SSL upgrade but it seemed to work in the end. The client ran ok and contacted our SVN server over https which tried to authorize the user against our LDAP server. The strange thing was that we got a "password mismatch" error from LDAP. We ran the client like this : svn info And were prompted for password (userid I guess was picked from the logged in id), anyway on the server log the username was shown correctly. This error happened for all our users, but we found out after a log time a workaround : svn info --username --password This worked ok! And now we were prompted to store user/password in the .subversion folder, and it was cached ok for later use without suppling user/pw. Now this is strange, anyone have an idea why this failed in the first place? Geir Note : All inquiries regarding Subversion, MKS and general Development servers should be directed to "EDB SourceControl System"
Branching with externals
Hi, I tried to use branching and switching in a project including external files and directories but the behavior turned out buggy/problematic in such a way that I'm wondering if I can use branches in a project with externals at all. However, I didn't see any related issues in the bug tracker. Any comments? Thanks, Vesa
Re: Branching with externals
On Aug 29, 2011, at 02:41, Vesa Paatero wrote: > I tried to use branching and switching in a project including external files > and directories but the behavior turned out buggy/problematic How so?
colon file in server repository structure
Hi, I found strange file on directory structure of my repository on server: "/svn/my_repository/db/revs/0/:". It has zero size and its name is ":" (without quotes) - colon. Does anyone know meaning of this file? I have several repositories, but this is only "colon file" I found. Problem is that I backup this part of Linux filesystem on WinXP drive via rsync and this file cannot be created on NTFS filesystem :D (or may be it can, bud i dont wanna do it - it seems wrong :D). I would like to know if i can safely delete this file (it seems that there are no useful data in it). I know i shouldnt directly manipulate with repository files on server, but I have strange feeling that this file shouldnt be there :D. Or maybe it can be fixed via some repository tool. Thank you, John
RE: Branching with externals
> > I tried to use branching and switching in a project including external > > files and directories but the behavior turned out buggy/problematic > How so? I got tree conflict errors whose cause were traceable to the externals. Seemingly, SVN tried to put the externals to the branch and failed either in creating the branch or in switching to the branch. My version of SVN is 1.6.12 and I'm using the TortoiseSVN client. Vesa
Re: colon file in server repository structure
Jan Kopidol wrote on Mon, Aug 29, 2011 at 10:45:27 +0200: > Hi, > > I found strange file on directory structure of my repository on > server: "/svn/my_repository/db/revs/0/:". It has zero size and its The FSFS backend does not use files named colon. I'd delete it and investigate how it was created. > name is ":" (without quotes) - colon. Does anyone know meaning of > this file? I have several repositories, but this is only "colon > file" I found. Problem is that I backup this part of Linux > filesystem on WinXP drive via rsync and this file cannot be created > on NTFS filesystem :D (or may be it can, bud i dont wanna do it - it > seems wrong :D). I would like to know if i can safely delete this > file (it seems that there are no useful data in it). I know i > shouldnt directly manipulate with repository files on server, but I > have strange feeling that this file shouldnt be there :D. Or maybe > it can be fixed via some repository tool. > > Thank you, > > John
RE: (How to ?) copy latest rev of a sub-tree to new repo
> After scratching my head for a while and reading documentation as best as I > can, I am not able to see a good method for doing the following. > > We use SVN to develop software for an embedded system. Our 'C' code is > developed in parts of the tree that are grouped by project. We have a > seperate tree containing the embedded file system. The file system tree's > binaries and libraries are populated automatically by using SVN externals > from the parts of the tree that we use to develop our code. In other words, > after a major source code change, the programmer commits the library or > executable and by the magic of SVN:externals is appears at the right place on > the file system. A developer only needs to check out his part of the repo, > but can automatically contribute to our final output, the embedded > filesystem. > > For releases we copy our trunk to a tag, rebuild all the code, commit the > libraries and binaries to the tag and then create our file system by pulling > in > the newly comitted binaries/libraries from that tag. That way, a release is > guarenteed to have libraries corrospond to the source code. It works well for > us. > > Problem is, it is not so great for creating a test release. For us to build > our > embedded file system, we *have* to pull its files from SVN and that means > a lot of commits only for testing. Our svn repo is 7GB+ and growing too > fast. > > So here is a simple solution - i thought - for a test release, we extract rev > HEAD from the trunk repository, copy to a temporary SVN repository > created on the fly. This will include all our svn:externals definitions. We > build > the code in the project trees, commit to the temporary repository and build > our file-system from it. If it is a bad test, we just delete the temp > repository. Fix the trunk in the real repo and start again. > > Here is where I need help. I can not find a way of extracting HEAD from a > sub-part of the repo to create a new temp repo. > > 1. svnadmin dump followed by a load would re-create our entire repository, > when I really only need a part. Yes, I could svndumpfilter as a second step > but we are now talking some massive CPU overhead. Secondly it forces us to > build on the same machine (right ?) since you can't dump a URL. Svnrdump can do this. It's a new util... I'm not sure if it's been released yet, or will only be released with 1.7. > > 2. svnsync can do copies of sub-trees (as of v1.5) but it would copy the > entire > history. > > 3. svn-hot-copy would copy the entire repo and all history. > > 4. svn export followed by svn import would lose all the SVN: externals - our > binaries would get build but never appear in the file-system tree. > > Am I missing a solution ? I'm not understanding why option 4 won't work. Can you not also create a "test" file-system tree using export as well? Sorry I can't be of more help. BOb
SVN on fileshare - user cannot commit - cannot open file 'txn-current-lock'
I have several SVN repositories on an Windows network fileshare. The user has full control, read, write, and just about every other permission that can be added. When trying to commit he gets the error: Can't open file '//fileshare/svnrepos/projectname/db/txn-current-lock': Permission denied It's being accessed via file:///, which I know is badbadterrible but I don't know how else to set it up given I am not an admin and this fileshare is all we have available. I've dug around a bit and been told I need to be using snvserve, but we don't have svnserve running on the remote share. I can try executing it from my machine but it just hangs, never prints anything. I can't install or really do much to the remote machine. I know it would be better to have this on an svn server, but to get this up and running in the mean time, what do I need to look at? (And ideally, how could I get an svnserver going? Would I need to talk to some of the admins that take care of that share?) Short term just getting it to where he can commit now, long term being the svnserver.. -- View this message in context: http://old.nabble.com/SVN-on-fileshare---user-cannot-commit---cannot-open-file-%27txn-current-lock%27-tp32359587p32359587.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: SVN on fileshare - user cannot commit - cannot open file 'txn-current-lock'
On Aug 29, 2011, at 14:42, this_thread wrote: > I have several SVN repositories on an Windows network fileshare. The user has > full control, read, write, and just about every other permission that can be > added. When trying to commit he gets the error: > > Can't open file '//fileshare/svnrepos/projectname/db/txn-current-lock': > Permission denied > > It's being accessed via file:///, which I know is badbadterrible but I don't > know how else to set it up given I am not an admin and this fileshare is all > we have available. > > I've dug around a bit and been told I need to be using snvserve, but we > don't have svnserve running on the remote share. I can try executing it from > my machine but it just hangs, never prints anything. I can't install or > really do much to the remote machine. > > I know it would be better to have this on an svn server, but to get this up > and running in the mean time, what do I need to look at? (And ideally, how > could I get an svnserver going? Would I need to talk to some of the admins > that take care of that share?) Short term just getting it to where he can > commit now, long term being the svnserver.. You need a server running svnserve, or apache with mod_dav_svn. Don't pursue doing this with a normal file server.
Re: SVN on fileshare - user cannot commit - cannot open file 'txn-current-lock'
Ryan Schmidt-80 wrote: > > > On Aug 29, 2011, at 14:42, this_thread wrote: > >> I have several SVN repositories on an Windows network fileshare. The user >> has >> full control, read, write, and just about every other permission that can >> be >> added. When trying to commit he gets the error: >> >> Can't open file '//fileshare/svnrepos/projectname/db/txn-current-lock': >> Permission denied >> >> It's being accessed via file:///, which I know is badbadterrible but I >> don't >> know how else to set it up given I am not an admin and this fileshare is >> all >> we have available. >> >> I've dug around a bit and been told I need to be using snvserve, but we >> don't have svnserve running on the remote share. I can try executing it >> from >> my machine but it just hangs, never prints anything. I can't install or >> really do much to the remote machine. >> >> I know it would be better to have this on an svn server, but to get this >> up >> and running in the mean time, what do I need to look at? (And ideally, >> how >> could I get an svnserver going? Would I need to talk to some of the >> admins >> that take care of that share?) Short term just getting it to where he >> can >> commit now, long term being the svnserver.. > > You need a server running svnserve, or apache with mod_dav_svn. Don't > pursue doing this with a normal file server. > > I understand this is bad in the long run, but again, for emphasis: I am not an admin on the server in question I am not an admin on any machine that I can reasonably set up an svnserve daemon I do not have access to any servers beyond the file shares Therefore, for the TIME BEING until I can get the IT support folks to generate one for us: is there any quick fix that will bandaid this for the time being? -- View this message in context: http://old.nabble.com/SVN-on-fileshare---user-cannot-commit---cannot-open-file-%27txn-current-lock%27-tp32359587p32360372.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: SVN on fileshare - user cannot commit - cannot open file 'txn-current-lock'
On Mon, Aug 29, 2011 at 17:38, this_thread wrote: > > > Ryan Schmidt-80 wrote: >> >> >> On Aug 29, 2011, at 14:42, this_thread wrote: >> >>> I have several SVN repositories on an Windows network fileshare. The user >>> has >>> full control, read, write, and just about every other permission that can >>> be >>> added. When trying to commit he gets the error: >>> >>> Can't open file '//fileshare/svnrepos/projectname/db/txn-current-lock': >>> Permission denied >>> >>> It's being accessed via file:///, which I know is badbadterrible but I >>> don't >>> know how else to set it up given I am not an admin and this fileshare is >>> all >>> we have available. >>> >>> I've dug around a bit and been told I need to be using snvserve, but we >>> don't have svnserve running on the remote share. I can try executing it >>> from >>> my machine but it just hangs, never prints anything. I can't install or >>> really do much to the remote machine. >>> >>> I know it would be better to have this on an svn server, but to get this >>> up >>> and running in the mean time, what do I need to look at? (And ideally, >>> how >>> could I get an svnserver going? Would I need to talk to some of the >>> admins >>> that take care of that share?) Short term just getting it to where he >>> can >>> commit now, long term being the svnserver.. >> >> You need a server running svnserve, or apache with mod_dav_svn. Don't >> pursue doing this with a normal file server. >> >> > > I understand this is bad in the long run, but again, for emphasis: > > I am not an admin on the server in question > I am not an admin on any machine that I can reasonably set up an svnserve > daemon > I do not have access to any servers beyond the file shares > > Therefore, for the TIME BEING until I can get the IT support folks to > generate one for us: is there any quick fix that will bandaid this for the > time being? It's bad in the short run too. If you're not the administrator, you have zero assurance that your repositories are safe in their current incarnation. One errant keystroke and it's all gone. Any bandaid you put on will give you a false sense of security. You need to get a proper server set up if you want to use Subversion safely.
