Re: Default Config Files
On May 11, 2011, at 01:48, Ben Simpson wrote: > I am running the current version of SVN on a CentOS 5.5 server, and am > looking for the the default user config file location. > > What I am trying to do is set the default ~/.subversion/servers file to > automatically not store passwords, but want to be able to set it once, and > when new users access SVN (from this machine) they get the file that is > already modified. I cant seem to find where it gets this file from originally. > > If this doesn't make any sense, let me know, and I will try and explain it > better.. There is no central server-side settings storage system. There is however the /etc/subversion directory (on the client machine) whose contents would be used as defaults on that client. http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html
Re: Chkeckout only a portion of a repoistory
On May 10, 2011, at 20:22, Gavin Beau Baumanis wrote: > We have a web application that uses Jenkins CI for keeping our staging server > up to date via svn update. > > Due to not thinking abut it properly in the beginning, > The staging site is actually a working copy of the entire repo (branches and > tags included) > > We however, only require the trunk. > > Is there a way, so that I can remove the branches and tags from a working > copy, leaving the trunk in place AND > not have any subsequent updates replace the now missing directories and still > have a clean WC? > > My initial thought is no, > And it is relatively easy to just blow-away the entire WC and just checkout > the trunk only; > But it will cause some downtime that I'd like to avoid if possible. Before Subversion 1.7, this is very easy, since each subdirectory of a working copy is itself a complete self-contained working copy. Let's say your working copy is at /path/to/wc (it contains directories trunk, branches, tags) and you (or this Jenkins thing) are currently updating it by running "svn up /path/to/wc". So instead just run (or tell Jenkins to run) "svn up /path/to/wc/trunk". Voila, you're only updating the trunk. You can now remove (using your normal OS commands, not svn commands) the branches and tags directories to save space. You can even remove the hidden /path/to/wc/.svn directory, and then /path/to/wc will not even be a working copy anymore, it'll just be a regular directory (/path/to/wc/trunk will be the remaining working copy). As of Subversion 1.7, working copy metadata will be consolidated in the root of the working copy, so this kind of working copy dissection will no longer be as straightforward to do.
Re: Find out whether a directory is external
On Wed, May 11, 2011 at 02:57, Markus Schaber wrote: > Hi, > > > > Is it true that the only way to find out whether a directory residing > somewhere deep in a working copy tree is included via “svn:externals” is to > check the parent directory? > Yes. Due to how WC metadata is handled, a directory in a WC doesn't "know" what's above it in the hierarchy. This may change with 1.7 but that's merely wild speculation based on the fact that the WC handling code has been completely redone.
Re: Default Config Files
On Wed, May 11, 2011 at 6:28 AM, Ryan Schmidt wrote: > > On May 11, 2011, at 01:48, Ben Simpson wrote: > >> I am running the current version of SVN on a CentOS 5.5 server, and am >> looking for the the default user config file location. >> >> What I am trying to do is set the default ~/.subversion/servers file to >> automatically not store passwords, but want to be able to set it once, and >> when new users access SVN (from this machine) they get the file that is >> already modified. I cant seem to find where it gets this file from >> originally. >> >> If this doesn't make any sense, let me know, and I will try and explain it >> better.. > > There is no central server-side settings storage system. There is however the > /etc/subversion directory (on the client machine) whose contents would be > used as defaults on that client. > > http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html First, upgrade to the CentOS 5.6 version of subversion, for both clients and servers. *NOW*. That gets you Subversion 1.6.x, which at least *ASKS* before storing those passwords in cleartext. It's a very large improvement in flexibility and performance. Note that once you touch a working copy with Subversion 1.6.x, it will auto-upgrade and you cannot gracefully roll it back to the Subversion 1.4.2 on CentOS 5.5, so be ready to update all your hosts. If you're running CentOS 4.x or 3.x, *STOP IT*. Upgrade before even considering using Subversion on them anymore, there's been too much development, and the backport is a nightmare. Second, this is also an *old* hobby horse of mine. http/https password mangement for clients in UNIX and Linux and CygWin is one of Subversion's long-standing security vulnerabilities. (TortoiseSVN and other Windows based tools apparently handle it much better.) The svn+ssh client, at least, does not do this. The svn+ssh client also allows the use of SSH keys, rather than login shells, that can be locked to read-only access or permit write access, but funnel all subversion access through a single authorized account, typically "svn". If you want anonymous read access, you can make the repositories live in /var/www/html/svn/. The problem with svn+ssh access is key management. There remains no Subversion equivalent of gitosis to central and gracefully manage SSH keys, and developers can get pretty cranky if they have to wait to get their SSH keys added. I'm hoping Wandisco's latest commercial offerings for Subversion handle this: I'm asking questions about it for other reasons, and they're deeply involved in the Subversion 1.7 development.
Re: Default Config Files
Nico Kadel-Garcia wrote on Wed, May 11, 2011 at 08:05:53 -0400: > On Wed, May 11, 2011 at 6:28 AM, Ryan Schmidt > wrote: > > > > On May 11, 2011, at 01:48, Ben Simpson wrote: > > > >> I am running the current version of SVN on a CentOS 5.5 server, and am > >> looking for the the default user config file location. > >> > >> What I am trying to do is set the default ~/.subversion/servers file to > >> automatically not store passwords, but want to be able to set it once, and > >> when new users access SVN (from this machine) they get the file that is > >> already modified. I cant seem to find where it gets this file from > >> originally. > >> > >> If this doesn't make any sense, let me know, and I will try and explain it > >> better.. > > > > There is no central server-side settings storage system. There is however > > the /etc/subversion directory (on the client machine) whose contents would > > be used as defaults on that client. > > > > http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html > > First, upgrade to the CentOS 5.6 version of subversion, for both > clients and servers. *NOW*. That gets you Subversion 1.6.x, which at > least *ASKS* before storing those passwords in cleartext. It's a very > large improvement in flexibility and performance. Note that once you > touch a working copy with Subversion 1.6.x, it will auto-upgrade and > you cannot gracefully roll it back to the Subversion 1.4.2 on CentOS > 5.5, so be ready to update all your hosts. > change-svn-wc-format.py
Re: Default Config Files
Nico Kadel-Garcia wrote on Wed, May 11, 2011 at 08:05:53 -0400: > Second, this is also an *old* hobby horse of mine. It's a dead horse, and not at all relevant to the OP's question.
AW: Find out whether a directory is external
Hi, Andy, > Von: Andy Levy [mailto:andy.l...@gmail.com] > > Is it true that the only way to find out whether a directory residing > > somewhere deep in a working copy tree is included via "svn:externals" > > is to check the parent directory? > > Yes. Due to how WC metadata is handled, a directory in a WC doesn't "know" > what's above it in the hierarchy. This may change with 1.7 but that's > merely wild speculation based on the fact that the WC handling code has > been completely redone. Ok, I see. Maybe this is also the reason for the following problem: When I commit several pathes, one of them being an external directory, I get an exception: "Are all the targets part of the same working copy?", SVN_ERR_WC_NOT_LOCKED. I cannot omit the external directory from the list of items to be commited (as it may contain property changes I want to commit), and I cannot use recursive commit on the parent directory (as this would commit other objects the user did not select for commit). Is there a workaround? Or is this question better submitted to the dev list? Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
AW: Find out whether a directory is external
Hi, > Von: Markus Schaber [mailto:m.scha...@3s-software.com] > When I commit several pathes, one of them being an external directory, I > get an exception: > "Are all the targets part of the same working copy?", > SVN_ERR_WC_NOT_LOCKED. Just some more explanation tot he situation: [In all the following cases, it is assumed that the external directory is from the same repository than the main working copy). I can commit files and directories from inside and outside the external directory in the same commit, as long as the external directory itself is not mentioned on the list of elements to commit. I can commit the external directory itself (with and without files and directories below the external directory), as long as no file or directory outside of the external directory is mentioned on the list of elements. I cannot commit the external directory itself (which has changed properties) together with any path in the working copy outside of the external directory. Is there a workaround? Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Find out whether a directory is external
On Wed, May 11, 2011 at 10:29, Markus Schaber wrote: > Hi, > >> Von: Markus Schaber [mailto:m.scha...@3s-software.com] >> When I commit several pathes, one of them being an external directory, > I >> get an exception: >> "Are all the targets part of the same working copy?", >> SVN_ERR_WC_NOT_LOCKED. > > Just some more explanation tot he situation: > > [In all the following cases, it is assumed that the external directory > is from the same repository than the main working copy). > > I can commit files and directories from inside and outside the external > directory in the same commit, as long as the external directory itself > is not mentioned on the list of elements to commit. > > I can commit the external directory itself (with and without files and > directories below the external directory), as long as no file or > directory outside of the external directory is mentioned on the list of > elements. > > I cannot commit the external directory itself (which has changed > properties) together with any path in the working copy outside of the > external directory. > > Is there a workaround? Externals, although they appear to be "in" your WC, are actually not part of the parent working copy. As a result, anyplace where you are successfully committing items both in the parent WC and the externals directory may be a bug, but definitely not "as intended" behavior. IOW, don't trust it. You should always commit items inside your external separately from items outside the external. If your external was sourced from another repository, you'd have no choice; when it works for externals sourced from the same repository, it's more chance than "working as designed." Scroll to the last few paragraphs of http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
Re: AW: Find out whether a directory is external
On 5/11/2011 9:29 AM, Markus Schaber wrote: Hi, Von: Markus Schaber [mailto:m.scha...@3s-software.com] When I commit several pathes, one of them being an external directory, I get an exception: "Are all the targets part of the same working copy?", SVN_ERR_WC_NOT_LOCKED. Just some more explanation tot he situation: [In all the following cases, it is assumed that the external directory is from the same repository than the main working copy). That would be a bad thing to assume in general. I can commit files and directories from inside and outside the external directory in the same commit, as long as the external directory itself is not mentioned on the list of elements to commit. I'd consider that accidental and not count on it. I can commit the external directory itself (with and without files and directories below the external directory), as long as no file or directory outside of the external directory is mentioned on the list of elements. That part makes sense. I cannot commit the external directory itself (which has changed properties) together with any path in the working copy outside of the external directory. Is there a workaround? If it is all in the same repository and you want it to be treated monolithically, why not move it to the layout you want instead of fighting with externals? Or if the referenced parts are really separate components, remember that and cd into the relevant directories when committing component changes. -- Les Mikesell lesmikes...@gmail.com
Re: Default Config Files
I appear to be running 1.6.x because it is asking me. My client wants that message to go away, so I found I can edit the servers file, and uncomment a couple lines to not store passwords at all, and it wont ask you. Thats what they want. Also, most of the users will be using TortoiseSVN on Windows machines, so it wont be a problem, but they still want the change.. So, would I just copy the files that I want into the /etc/subversion directory? That directory on my machine is blank.. Thanks! ben On Wed, May 11, 2011 at 5:50 AM, Daniel Shahaf wrote: > Nico Kadel-Garcia wrote on Wed, May 11, 2011 at 08:05:53 -0400: > > Second, this is also an *old* hobby horse of mine. > > It's a dead horse, and not at all relevant to the OP's question. >
Random files being "reverted" on one repository
Hi List, We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a development company, and have over 150 active repositories, but we are not subversion experts. We are experiencing an issue with just one particular repository. When programmers run an update against this one repository (using either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they observe that they sometimes get---to coin their term---"frankenstein" versions of arbitrary files. As an example scenario: 1) - Developer A: adds, edits and commits a file X, 2) - Developer A: later, again edits and commits file X, 3) - Developer A: still later, again edits and commits file X, 4) - Developer N: who has never before seen file X, runs an update. She gets a weird version of file X which contains only *some* lines of the set of changes made by Developer A in each of the edit/commit sessions (1), (2), and (3). We cannot replicate the problem on demand, but it recurs with (seemingly) random files at random times. The worst thing is that when an update silently "reverts" some unknown file (to a "frankenstein" version), it is subsequently committed as a new version by the unsuspecting developer. We've tried exporting and re-importing the code to a new repository, but the issue has persisted. "Svnadmin verify" finds no errors in any revisions. Our latest move was to disable the Windows Search service, but if that's really the problem, our other developers should be seeing this with other repositories. Any advice on how to duplicate/troubleshoot the cause of this problem will be greatly appreciated. Thank you, Dave
Re: Random files being "reverted" on one repository
On Wednesday 11 May 2011, Dave Tingling wrote: > Hi List, > > We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a > development company, and have over 150 active repositories, but we are > not subversion experts. We are experiencing an issue with just one > particular repository. > > When programmers run an update against this one repository (using either > TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they > observe that they sometimes get---to coin their term---"frankenstein" > versions of arbitrary files. As an example scenario: > > 1) - Developer A: adds, edits and commits a file X, > 2) - Developer A: later, again edits and commits file X, > 3) - Developer A: still later, again edits and commits file X, > 4) - Developer N: who has never before seen file X, runs an update. She > gets a weird version of file X which contains only *some* lines of the > set of changes made by Developer A in each of the edit/commit sessions > (1), (2), and (3). > > We cannot replicate the problem on demand, but it recurs with > (seemingly) random files at random times. The worst thing is that when > an update silently "reverts" some unknown file (to a "frankenstein" > version), it is subsequently committed as a new version by the > unsuspecting developer. > > We've tried exporting and re-importing the code to a new repository, but > the issue has persisted. "Svnadmin verify" finds no errors in any > revisions. Our latest move was to disable the Windows Search service, > but if that's really the problem, our other developers should be seeing > this with other repositories. Any advice on how to > duplicate/troubleshoot the cause of this problem will be greatly > appreciated. > > Thank you, > Dave Hi, I've seen something like this before when some of the users were remote nd were accessing the repository via a SVK mirror. The mirror was reverting files prior to committing to what I presume it thought the state should be. This was some years ago, but if I recall correctly the commits for the reverted files did not have any commit message. I don't know if it was an artifact of the setup we had (I never did the setup) but commits coming via the SVK mirror would be from a single user but the real user would be part of the commit message. Could something like this be happening for you? Campbell -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Re: Random files being "reverted" on one repository
Guten Tag Dave Tingling, am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie: > 1) - Developer A: adds, edits and commits a file X, > 2) - Developer A: later, again edits and commits file X, > 3) - Developer A: still later, again edits and commits file X, > 4) - Developer N: who has never before seen file X, runs an update. She > gets a weird version of file X which contains only *some* lines of the > set of changes made by Developer A in each of the edit/commit sessions > (1), (2), and (3). And this behaviour is reproducible, meaning that every time the file x is deleted from the local working copy of dev N on each and every update the newly created file is freaky? Is it freaky on clean checkouts, too? > We cannot replicate the problem on demand, but it recurs with > (seemingly) random files at random times. The worst thing is that when > an update silently "reverts" some unknown file (to a "frankenstein" > version), it is subsequently committed as a new version by the > unsuspecting developer. How do you know that the update is the problem? If the file in the repository looks fine, I don't think the problem comes with the update, but afterwards, on any build actions or stuff like that. As you say: The freaky file is committed by dev N and that is the problem, between update and commit it is somehow changed. The update process just make changes to the local file, if already present, that are on the server and it's pretty likely that this will work as expected. The interesting part is between update and commit of dev N and in your case i would look at the diffs to maybe get an idea of the tool or process or whatever is responsible for the changes in the file. Maybe there's something common in every changes? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Default Config Files
On Wed, May 11, 2011 at 11:38, Ben Simpson wrote: > I appear to be running 1.6.x because it is asking me. My client wants that > message to go away, so I found I can edit the servers file, and uncomment a > couple lines to not store passwords at all, and it wont ask you. Thats what > they want. Also, most of the users will be using TortoiseSVN on Windows > machines, so it wont be a problem, but they still want the change.. > So, would I just copy the files that I want into the /etc/subversion > directory? That directory on my machine is blank.. As stated before, that would only affect users on that (I assume) Linux box who have not run the svn client previously. It will not control behavior for remote clients, nor will it change the behavior for users who already have a ~/.subversion directory. I know that directory applies to the config (~/.subversion/config once it's been copied) file, not sure about servers. You can prevent the client from caching credentials in ~/.subversion/config (the store-auth-creds setting) but you can't stop a user from changing their own config after the fact.
Re: Random files being "reverted" on one repository
fsfs or bdb? Tried 1.5.7 / 1.6.16 server? Dave Tingling wrote on Wed, May 11, 2011 at 11:50:58 -0400: > Hi List, > > We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a > development company, and have over 150 active repositories, but we > are not subversion experts. We are experiencing an issue with just > one particular repository. > > When programmers run an update against this one repository (using > either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro > SP1), they observe that they sometimes get---to coin their > term---"frankenstein" versions of arbitrary files. As an example > scenario: > > 1) - Developer A: adds, edits and commits a file X, > 2) - Developer A: later, again edits and commits file X, > 3) - Developer A: still later, again edits and commits file X, > 4) - Developer N: who has never before seen file X, runs an update. > She gets a weird version of file X which contains only *some* lines > of the set of changes made by Developer A in each of the edit/commit > sessions (1), (2), and (3). > > We cannot replicate the problem on demand, but it recurs with > (seemingly) random files at random times. The worst thing is that > when an update silently "reverts" some unknown file (to a > "frankenstein" version), it is subsequently committed as a new > version by the unsuspecting developer. > > We've tried exporting and re-importing the code to a new repository, > but the issue has persisted. "Svnadmin verify" finds no errors in > any revisions. Our latest move was to disable the Windows Search > service, but if that's really the problem, our other developers > should be seeing this with other repositories. Any advice on how to > duplicate/troubleshoot the cause of this problem will be greatly > appreciated. > > Thank you, > Dave
Re: Random files being "reverted" on one repository
Campbell Allan wrote: On Wednesday 11 May 2011, Dave Tingling wrote: Hi List, We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a development company, and have over 150 active repositories, but we are not subversion experts. We are experiencing an issue with just one particular repository. When programmers run an update against this one repository (using either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they observe that they sometimes get---to coin their term---"frankenstein" versions of arbitrary files. As an example scenario: 1) - Developer A: adds, edits and commits a file X, 2) - Developer A: later, again edits and commits file X, 3) - Developer A: still later, again edits and commits file X, 4) - Developer N: who has never before seen file X, runs an update. She gets a weird version of file X which contains only *some* lines of the set of changes made by Developer A in each of the edit/commit sessions (1), (2), and (3). We cannot replicate the problem on demand, but it recurs with (seemingly) random files at random times. The worst thing is that when an update silently "reverts" some unknown file (to a "frankenstein" version), it is subsequently committed as a new version by the unsuspecting developer. We've tried exporting and re-importing the code to a new repository, but the issue has persisted. "Svnadmin verify" finds no errors in any revisions. Our latest move was to disable the Windows Search service, but if that's really the problem, our other developers should be seeing this with other repositories. Any advice on how to duplicate/troubleshoot the cause of this problem will be greatly appreciated. Thank you, Dave Hi, I've seen something like this before when some of the users were remote nd were accessing the repository via a SVK mirror. The mirror was reverting files prior to committing to what I presume it thought the state should be. This was some years ago, but if I recall correctly the commits for the reverted files did not have any commit message. I don't know if it was an artifact of the setup we had (I never did the setup) but commits coming via the SVK mirror would be from a single user but the real user would be part of the commit message. Could something like this be happening for you? Campbell Thanks Campbell. No remote users, no SVK mirror in place, nor anything intermediate between the server and clients. -Dave
Re: Random files being "reverted" on one repository
Daniel Shahaf wrote: fsfs or bdb? Tried 1.5.7 / 1.6.16 server? Dave Tingling wrote on Wed, May 11, 2011 at 11:50:58 -0400: Hi List, We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a development company, and have over 150 active repositories, but we are not subversion experts. We are experiencing an issue with just one particular repository. When programmers run an update against this one repository (using either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they observe that they sometimes get---to coin their term---"frankenstein" versions of arbitrary files. As an example scenario: 1) - Developer A: adds, edits and commits a file X, 2) - Developer A: later, again edits and commits file X, 3) - Developer A: still later, again edits and commits file X, 4) - Developer N: who has never before seen file X, runs an update. She gets a weird version of file X which contains only *some* lines of the set of changes made by Developer A in each of the edit/commit sessions (1), (2), and (3). We cannot replicate the problem on demand, but it recurs with (seemingly) random files at random times. The worst thing is that when an update silently "reverts" some unknown file (to a "frankenstein" version), it is subsequently committed as a new version by the unsuspecting developer. We've tried exporting and re-importing the code to a new repository, but the issue has persisted. "Svnadmin verify" finds no errors in any revisions. Our latest move was to disable the Windows Search service, but if that's really the problem, our other developers should be seeing this with other repositories. Any advice on how to duplicate/troubleshoot the cause of this problem will be greatly appreciated. Thank you, Dave FSFS. My understanding is that the 1.4.2 (reported by running "svn --version" on the server) is what ships with CentOS 5.5, and that it is "backported" so that it includes recent updates, bugfixes, etc. I'm not sure how to check what repo format is on the server, though. We have not yet tried 1.5.7 or 1.6.16 server. Thanks, -Dave
Re: Random files being "reverted" on one repository
Thorsten Schöning wrote: Guten Tag Dave Tingling, am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie: 1) - Developer A: adds, edits and commits a file X, 2) - Developer A: later, again edits and commits file X, 3) - Developer A: still later, again edits and commits file X, 4) - Developer N: who has never before seen file X, runs an update. She gets a weird version of file X which contains only *some* lines of the set of changes made by Developer A in each of the edit/commit sessions (1), (2), and (3). And this behaviour is reproducible, meaning that every time the file x is deleted from the local working copy of dev N on each and every update the newly created file is freaky? Is it freaky on clean checkouts, too? We cannot replicate the problem on demand, but it recurs with (seemingly) random files at random times. The worst thing is that when an update silently "reverts" some unknown file (to a "frankenstein" version), it is subsequently committed as a new version by the unsuspecting developer. How do you know that the update is the problem? If the file in the repository looks fine, I don't think the problem comes with the update, but afterwards, on any build actions or stuff like that. As you say: The freaky file is committed by dev N and that is the problem, between update and commit it is somehow changed. The update process just make changes to the local file, if already present, that are on the server and it's pretty likely that this will work as expected. The interesting part is between update and commit of dev N and in your case i would look at the diffs to maybe get an idea of the tool or process or whatever is responsible for the changes in the file. Maybe there's something common in every changes? Mit freundlichen Grüßen, Thorsten Schöning Thanks for the quick reply and your guidance Thorsten. I'm not 100% sure. I'll work with the developers to clarify, and then will report back. Thank you, -Dave
Re: Random files being "reverted" on one repository
Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400: > I'm not sure how to check what repo format is on the server, though. cat $REPOS/format cat $REPOS/db/fs-type cat $REPOS/db/format (it'd be nice to document this in the FAQ along with the format number -> minor version number mappings)
Re: Random files being "reverted" on one repository
Thanks Daniel. Results from in the repo dir on the server:: [dt@s..]$ cat format 5 [dt@s..]$ cat db/fs-type fsfs [dt@s..]$ cat db/format 2 Daniel Shahaf wrote: Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400: I'm not sure how to check what repo format is on the server, though. cat $REPOS/format cat $REPOS/db/fs-type cat $REPOS/db/format (it'd be nice to document this in the FAQ along with the format number -> minor version number mappings) -- Dave Tingling Business Process Analyst Info Tech, Inc. 352-381-4512 (direct) 352-381- (fax)
Re: Random files being "reverted" on one repository
Which tells me your repository was created by Subversion 1.4. Nothing unexpected... Dave Tingling wrote on Wed, May 11, 2011 at 14:44:52 -0400: > Thanks Daniel. Results from in the repo dir on the server:: > > [dt@s..]$ cat format > 5 > [dt@s..]$ cat db/fs-type > fsfs > [dt@s..]$ cat db/format > 2 > > Daniel Shahaf wrote: > >Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400: > >>I'm not sure how to check what repo format is on the server, though. > >cat $REPOS/format > >cat $REPOS/db/fs-type > >cat $REPOS/db/format > > > > > >(it'd be nice to document this in the FAQ along with the > >format number -> minor version number mappings) > > > -- > Dave Tingling > Business Process Analyst > Info Tech, Inc. > 352-381-4512 (direct) > 352-381- (fax) >
Re: Random files being "reverted" on one repository
Thorsten Schöning wrote: Guten Tag Dave Tingling, am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie: And this behaviour is reproducible, meaning that every time the file x is deleted from the local working copy of dev N on each and every update the newly created file is freaky? Is it freaky on clean checkouts, too? Thorsten, It is not reproducible as you propose above: deleting the local file and updating again has (so far) resulted in a good copy. I received these further comments from one of the developers: In this case, there are no build actions to speak of. These are pretty much just perl files, and we don't use visual studio or any project management type apps. A handful of us use Komodo for project management, but the problem seems to impact people regardless of editor or SVN client. The problem does in fact happen during the update phase, because other people can do the same update and get the correct version of the file. When someone experiences the error, Their local copy will show as modified immediately after the update, and attempting to commit the working copy directory will include these changes. No conflict will be detected. To clarify, I confirmed that they do not use Komodo to talk directly to the server; they only point it to working-copies. Thanks, -Dave
Re: Random files being "reverted" on one repository
Daniel Shahaf wrote: Which tells me your repository was created by Subversion 1.4. Nothing unexpected... I've learned that clients update their working-copy layout to whatever that client is built for. Considering http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version, I realize that our 1.6.x clients indeed have '10' on the first line of .svn/entries. What do these $REPOS/format = 5 and $REPOS/db/format = 2 each mean, please? (I'll be happy to document in the FAQ if I can :-) Is it possible that we're seeing this problem because of using 1.6 clients against this server? Thanks, -Dave
Re: Random files being "reverted" on one repository
2011/5/11 Dave Tingling : > Hi List, > > We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a development > company, and have over 150 active repositories, but we are not subversion > experts. We are experiencing an issue with just one particular repository. > > When programmers run an update against this one repository (using either > TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they > observe that they sometimes get---to coin their term---"frankenstein" > versions of arbitrary files. As an example scenario: > > 1) - Developer A: adds, edits and commits a file X, > 2) - Developer A: later, again edits and commits file X, > 3) - Developer A: still later, again edits and commits file X, > 4) - Developer N: who has never before seen file X, runs an update. She gets > a weird version of file X which contains only *some* lines of the set of > changes made by Developer A in each of the edit/commit sessions (1), (2), > and (3). > On client: it is easy to break one's working copy if you move directories around mindlessly. One should always use svn command when moving around directories, and never the system commands. http://tortoisesvn.net/mostforgottenfeature.html On *nix that is the difference between "mv" and "svn mv". If you mv a directory the ".svn" subdirectory of it is moved along, but still points to the old location. Trying to commit any file in the moved directory will actually commit it to the original location, because of that stale ".svn" subdirectory. The "svn info" command (or Subversion tab in file properties dialog in Windows Explorer on a PC where TortoiseSVN is installed) what is repository path for any particular file in the working copy. On the server: what protocol you are using to access the repository and commit the files? I hope there is no proxy in between you and client, that performs some sort of url rewriting? > We administer subversion (v 1.4.2, r22196 on CentOS 5.5) Anyway, 1.4.2 is very old, and misses a number of fixes in 1.4.x line, not to mention the later versions. In some other thread recently when "CentOS 5.5" was mentioned one of the answers was to upgrade to 5.6 ASAP. Best regards, Konstantin Kolinko
Re: Random files being "reverted" on one repository
Dave Tingling wrote on Wed, May 11, 2011 at 16:03:20 -0400: > Daniel Shahaf wrote: > >Which tells me your repository was created by Subversion 1.4. Nothing > >unexpected... > I've learned that clients update their working-copy layout to > whatever that client is built for. Considering > http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version, > I realize that our 1.6.x clients indeed have '10' on the first line > of .svn/entries. > Correct, but that's a client-side issue, which is a few miles (and layers of abstraction) away from where we were two levels of >-quoting ago... > What do these $REPOS/format = 5 and $REPOS/db/format = 2 each > mean, please? These are the repository format number and the filesystem backend format number. When svnadmin 1.4 sees a format number greater than 2 on a FSFS repository, it will abort with an error to the effect of "This repository is newer than I know how to handle". (It doesn't know how to modify a format-3 FSFS without corrupting it.) Ditto for the other format files. Specific details currently live at the documentation comments of the following macros: subversion/libsvn_repos/repos.h:SVN_REPOS__FORMAT_NUMBER subversion/libsvn_fs_fs/fs.h:SVN_FS_FS__FORMAT_NUMBER subversion/libsvn_fs_base/fs.h:SVN_FS_BASE__FORMAT_NUMBER (In a nutshell: the filesystem is everything under the db/ directory --- the versioned tree and revprops; the repository is everything under db/'s parent directory; the filesystem format number is private to the concrete FS provider (fsfs or bdb), rather than to the FS library itself) > (I'll be happy to document in the FAQ if I can :-) Thanks for the readiness :-) The FAQ source lives at http://svn.apache.org/repos/asf/subversion/site/publish/faq.html, and patch submission guideliens are at http://subversion.apache.org/patches. > Is it possible that we're seeing this problem because of using 1.6 > clients against this server? > It's possible that we have some bugs in the compatibility code for 1.6.16 clients and 1.4.x servers. > Thanks, > -Dave
Re: Subversion Setup Question
On 2011-05-09 21:21, Chris McGrath wrote: [...] > Our current setup is: > > 1 development server that we work off of. This is MAC based. > 1 production web server hosted with Rackspace that is Windows based. > 1 database server hosted with Rackspace that is Windows based. [...] > So the current work flow is we work off of the files on the > development server and when ready we push them to the production server. > > With this in mind, can someone point me in the direction of a decent > workflow that utilizes subversion? [...] http://www.google.com/search?hl=&q=subversion+for+web+development Seriously, there are quite a few user reports around that should give you an idea of what people found useful in their scenarios. This one looks like a good starting point: http://blogs.sitepoint.com/using-svn-for-web-development/ -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de
Re: Default Config Files
On Wed, May 11, 2011 at 8:50 AM, Daniel Shahaf wrote: > Nico Kadel-Garcia wrote on Wed, May 11, 2011 at 08:05:53 -0400: >> Second, this is also an *old* hobby horse of mine. > > It's a dead horse, and not at all relevant to the OP's question. > Hey, I'm not the one who brought up the "how do you prevent clients from storing passwords in cleartext" issue underlying this thread.
AW: AW: Find out whether a directory is external
Hi, Les, > Von: Les Mikesell [mailto:lesmikes...@gmail.com] > > [In all the following cases, it is assumed that the external directory > > is from the same repository than the main working copy). > > That would be a bad thing to assume in general. I know that I cannot commit into several different repositories at the same time (subversion does not support 2 phase commit or similar mechanisms), that's why I decided to ignore that cases. > > I can commit files and directories from inside and outside the > > external directory in the same commit, as long as the external > > directory itself is not mentioned on the list of elements to commit. > > I'd consider that accidental and not count on it. Accidental. It seems that svn is more limited than I thought [1]. > > I can commit the external directory itself (with and without files and > > directories below the external directory), as long as no file or > > directory outside of the external directory is mentioned on the list > > of elements. > > That part makes sense. > > I cannot commit the external directory itself (which has changed > > properties) together with any path in the working copy outside of the > > external directory. > > > > Is there a workaround? > > If it is all in the same repository and you want it to be treated > monolithically, why not move it to the layout you want instead of > fighting with externals? I'm working on a SharpSNV based Subversion plugin for the CoDeSys IDE, and the project tree there has some logical restrictions which do not allow the user to choose a completely free layout. And although we need a mapping layer between the internal project tree and the subversion working copy[2], we want to keep the layout of the working copy tree at least similar to the project tree. Additionally, we want to enable the user to include subtrees via externals from other locations - for example, he can include a complex device tree via externals, and thus reference it from several projects (which contain different applications for similar hardware). This sharing is not possible (or at least not with the same semantics) when using svn cp or other mechanisms. > Or if the referenced parts are really > separate components, remember that and cd into the relevant directories > when committing component changes. We want to put as less limits on the user as possible, but it seems that restricting commits to not cross external borders seems to be the only comprehensible behavior we can provide for our users in this case. Having it work in some cases, but not in others (depending on whether the external root is modified or not) seems to be too complicated teach our users. But I should stop whining now, and try to produce working code[3]. Regards, Markus Schaber [1] IIRC, years ago, when I used an svnkit based Eclipse plugin on linux, it was normal for me to commit files of two different projects (and thus different working copies) if they belong to the same repository. (Which makes sense in some light, as in pre-1.7, every directory is self contained, and the server does need to know about unchanged parent directories when committing.) When using svn command line and SharpSVN later, it found it to be a somehow artificial restriction that the "original" subversion client is not capable of doing that. So I was happy to find out later when using TortoiseSVN that I was now able to commit files from inside of same-repository externals in the same commit. First, I suspected that TortoiseSVN is doing some internal magic, but as I could reproduce that with the command line, I did assume that this was intentional. [2] Some of the reasons for that mapping layer are: Our project tree is not based on a directory layout, but saved in a single file in an internal database. The tree does not distinct between folders and objects, but arbitrary objects can have children, e. G. a device has buses, the buses have other devices plugged in. And a parent may have more than one child with the same name, e. G. several empty slots. This architecture is wired deeply into the product, and cannot be changed "just for a SVN plugin". [3] Here at work, we currently only have very limited time to contribute upstream. I wanted to do that at home in my spare time (as I used to do under my former employees when I worked with Linux), but I failed hard to find a way to build SharpSVN with only free (as in beer) tools. Two days of wasted time, and I'm not able to spend my private money for visual studio full version.
Re: Random files being "reverted" on one repository
Guten Tag Dave Tingling, am Mittwoch, 11. Mai 2011 um 22:03 schrieben Sie: > Is it > possible that we're seeing this problem because of using 1.6 clients > against this server? I don't think so, we use Subversion 1.4.x as server and bleeding edge TortoiseSVN with Subversion 1.6.x libs without any problems for month. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
