Re: Random files being "reverted" on one repository
Guten Tag Dave Tingling, am Mittwoch, 11. Mai 2011 um 21:40 schrieben Sie: >> 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. I would try to test a bit: Take a dev where the file never was freaky and let him produce small changes which are committable, e.g. add a newline at the end of the file and remove it or stuff like that. But it should be always the same changes. After each change let your problematic developer N update the file and see if the error happens and if it always results in the same wrong changes. I can't believe the error is in the subversion code, sounds more like a client problem to me. Client side scripts, programs locking the file and all that kind of stuff. 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: AW: AW: Find out whether a directory is external
On 5/12/11 1:39 AM, Markus Schaber wrote: 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]. Remember that a more typical use of externals is to include components that have their own separate release schedules. That is, you very often use tags as targets at least as the including project nears its own release, and thus you would not do any changes within that already-frozen component version subdirectory. That might be different in early stages of development where there is only one project using the component, but it's not something you should just ignore since the usual way to manage them is to adjust the external target to new tags as the component releases advance instead of expecting to commit in the workspace it pulls in. 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). Including the subtrees makes sense, but letting multiple upper level projects commit to them concurrently without being aware of that may not - especially if you ever need to freeze the contents for one project while the others are still changing. This sharing is not possible (or at least not with the same semantics) when using svn cp or other mechanisms. They'll become independent branches that can diverge if you copy them. You'd have to merge subsequent changes. That's probably worse than changing the externals to point to a different tag when you want to pick up changes. -- Les Mikesell lesmikes...@gmail.com
Re: Find out whether a directory is external
Hi, Les, > Von: Les Mikesell [mailto:lesmikes...@gmail.com] > Remember that a more typical use of externals is to include components > that have their own separate release schedules. Yes, in that light, it makes acutally sense to exclude externals from the commit by default, so the user has to explicitly select them for commit. In our use case, the imported subtrees are expected to be relatively stable, so I think this is not so far from your typical use case. I'll go the way of excluding externals from the commit by default, and forbid commits that include objects of different "externality". This solution is explainable to the users, and it is implementable on my side. Regards, Markus Schaber
Re: Random files being "reverted" on one repository
Thanks for those tips Konstantin. There are about 16 developers. Is there anything I can look at on the server side to determine whether such bad directory copy/moves have been done, and perhaps by whom? On the server: what protocol you are using to access the repository and commit the files? HTTPS...I'm not sure what mechanisms happen "within" or "lower than" that. Is this a helpful answer? If you need more info, please let me know how I can find it out. I personally am a facilitator for researching this issue, I'm not an admin. I hope there is no proxy in between you and client, that performs some sort of url rewriting? No proxy, no 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. Upgrading is non-trivial for us, for internal policy reasons (recall 150+ active repos). We realize that "upgrade now" would be a very strong encouragement in this forum, and understand that rationale. With due respect to that idea, I'm hoping we can identify why only one repository manifests this issue, and maybe why, after an export / import to a new repository, the problem appears in the new repo. Again, thank you very much. -Dave
RE: Random files being "reverted" on one repository
> Thanks for those tips Konstantin. > > There are about 16 developers. Is there anything I can look at on > the > server side to determine whether such bad directory copy/moves have > been > done, and perhaps by whom? > > > On the server: what protocol you are using to access the > repository and > > commit the files? > HTTPS...I'm not sure what mechanisms happen "within" or "lower > than" > that. Is this a helpful answer? If you need more info, please let > me > know how I can find it out. I personally am a facilitator for > researching this issue, I'm not an admin. > > > I hope there is no proxy in between you and client, > > that performs some sort of url rewriting? > > > No proxy, no 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. > > > Upgrading is non-trivial for us, for internal policy reasons > (recall > 150+ active repos). We realize that "upgrade now" would be a very > strong > encouragement in this forum, and understand that rationale. With > due > respect to that idea, I'm hoping we can identify why only one > repository > manifests this issue, and maybe why, after an export / import to a > new > repository, the problem appears in the new repo. Does the same team us more than one repository? Or is each repo used by different people and teams? Is the update funky when there is no file on the disk, or only when merging into an existing file? What encoding are the files using? I have found that svn doesn't really work well with Unicode files. Is it always the same file(s) or different ones each time? BOb
Re: Random files being "reverted" on one repository
Thorsten Schöning wrote: I would try to test a bit: Take a dev where the file never was freaky and let him produce small changes which are committable, e.g. add a newline at the end of the file and remove it or stuff like that. But it should be always the same changes. We will. Let me make sure I understand you: you're suggesting testing multiple commits, but each consecutive commit will be an "undoing" of the previous change. If that's true, after many many commits, I have only ever really committed two different variations of the file, in alternation. Is that what you intend? Assuming I understood you correctly above, would there be any value if I commit a completely new change to the same file each time, perhaps (for agument's sake) adding a new, predictable, unique line to the file? I would add the numeral '1' as line one, then next time add the numeral '2' as line 2, etc etc. always appending. What do you think? After each change let your problematic developer N update the file and see if the error happens and if it always results in the same wrong changes. Understood. Just to clarify our situation, there no single one problematic developer (nor file, for that matter). This could happen to anyone of the team---when some random person updates, a file is "wrong". It could be any one developer, any file. I can't believe the error is in the subversion code, sounds more like a client problem to me. Client side scripts, programs locking the file and all that kind of stuff. We are inclined to agree. Will proceed to test. Thanks very much. -Dave
Re: Random files being "reverted" on one repository
Guten Tag Dave Tingling, am Donnerstag, 12. Mai 2011 um 16:26 schrieben Sie: > We will. Let me make sure I understand you: you're suggesting testing > multiple commits, but each consecutive commit will be an "undoing" of > the previous change. If that's true, after many many commits, I have > only ever really committed two different variations of the file, in > alternation. Is that what you intend? Yes. > Assuming I understood you correctly above, would there be any value if I > commit a completely new change to the same file each time, perhaps (for > agument's sake) adding a new, predictable, unique line to the file? I > would add the numeral '1' as line one, then next time add the numeral > '2' as line 2, etc etc. always appending. What do you think? Using this approach you get to many differences over time and maybe it's too hard to see any correlations to the changes made which result in the freaky file. You only add one line in your commit but the result is that you never repeat the exactly two updates you have with my suggestion. You always have a new file with completely different content and not only to versions of the file. But I'm really only guessing, your problem really sounds strange. > Understood. Just to clarify our situation, there no single one > problematic developer (nor file, for that matter). This could happen to > anyone of the team---when some random person updates, a file is "wrong". > It could be any one developer, any file. You have to start somewhere. In problems like yours I would suggest running Filemon during the update but the logs surely will get huge and if you manage to get the error itself reproducible somehow running Filemon next time will be of more benefit. 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: Random files being "reverted" on one repository
Hi Bob, Does the same team us more than one repository? Or is each repo used by different people and teams? Some members of this team do work with other repositories. But this small team (7-10 active devs) is the only one that touches this problematic repository. Is the update funky when there is no file on the disk, or only when merging into an existing file? Both are true...if the file never existed locally before, it arrives funky. And if it did exist before, it ends up funky. What encoding are the files using? I have found that svn doesn't really work well with Unicode files. I had thought that different encoding on different workstations/files might be an issue, but don't know of a good way to investigate (I found a Unix tool, but nothing concrete for Win7). Did you mean the files on the various workstations, or are you thinking of some setting on the server-side? Please suggest how to best check the encoding(s?) to answer your question. I should mention that at least one member of this team is using a 32-bit PC/OS and 32-bit current version of Tortoise, the others are using 64-bit versions of the OS/Tortoise combo. Is it always the same file(s) or different ones each time? Different files each time the incident is observed. This incident is not observed after every update---only occasionally. Thanks, -Dave
RE: Random files being "reverted" on one repository
> Hi Bob, > > Does the same team us more than one repository? Or is each repo > used by different people and teams? > > > > > Some members of this team do work with other repositories. But this > small team (7-10 active devs) is the only one that touches this > problematic repository. This makes me think it isn't the repository but the users and the tools/procedures they are using. > > Is the update funky when there is no file on the disk, or only > when merging into an existing file? > > > > > Both are true...if the file never existed locally before, it > arrives > funky. And if it did exist before, it ends up funky. Ok, this leaves out the encoding possibility... because I think that would only show issues during an update in which it is merging changes with the current file on disk. > > What encoding are the files using? I have found that svn doesn't > really work well with Unicode files. > > > I had thought that different encoding on different > workstations/files > might be an issue, but don't know of a good way to investigate (I > found > a Unix tool, but nothing concrete for Win7). Did you mean the files > on > the various workstations, or are you thinking of some setting on > the > server-side? Please suggest how to best check the encoding(s?) to > answer > your question. > Most good editors allow you to view the current encoding on a file. I use Notepad++ and it is able to tell you the encoding of a file you open. You also might want to see if svn:mime-type is set on any of the files that have problems. > I should mention that at least one member of this team is using a > 32-bit > PC/OS and 32-bit current version of Tortoise, the others are using > 64-bit versions of the OS/Tortoise combo. > > Is it always the same file(s) or different ones each time? > > > Different files each time the incident is observed. This incident > is not > observed after every update---only occasionally. Yes, that's the worst kind of problem to fix. Although, I'm sure you will figure it out when you find that it isn't "random" and actually happens after "something specific" each time. But, until you narrow that down I doubt you'll be able to "fix" it. BOb
Re: Random files being "reverted" on one repository
2011/5/12 Dave Tingling : > Thanks for those tips Konstantin. > > There are about 16 developers. Is there anything I can look at on the server > side to determine whether such bad directory copy/moves have been done, and > perhaps by whom? > When developer B notices "Frankenstein" file appearing in his working copy he should 1. Look at the history of this file to find who committed it. That is "svn log --limit 3" command. (Or with limit of 1, only recent entries do matter). (Or using TortoiseSVN > Log command in its menu). 2. From the history find who and when committed the file. Let's say it was developer A. 3. Go to A and ask what changes were committed and call "svn info" on that file in A's working copy. (Or using Windows Explorer > File Properties > look at "Subversion" tab, as I wrote before). Pay attention to the file's path in repository. In TortoiseSVN there is "Change for modifications" dialog that I think should show if anything is wrong with files hierarchy in the working copy. >> On the server: what protocol you are using to access the repository and >> commit the files? > > HTTPS...I'm not sure what mechanisms happen "within" or "lower than" that. > Is this a helpful answer? If you need more info, please let me know how I > can find it out. I personally am a facilitator for researching this issue, > I'm not an admin. This is good. HTTPS passes proxies safely and unchanged. One more suggestion: you might consider about installing a post-commit hook at the repository. Tasks that can be performed by such a hook: a) make a dump of the recent commit, b) send a copy of commit diff to an e-mail address. etc. Best regards, Konstantin Kolinko
