Re: something about permission
肖晗 xiaohan2012 at gmail.com writes: I set up a svn server on my own Ubuntu\Linux. When I enter commands like svn commit filename, the terminal will remind me that I have no permission to do that.(Of course, except for the case when I add sudo to the head) Then I wonder, if clients from different PCs try to commit something, how do they get such permission? Thanks in advance! I'm new to subversion too, but I think your permission issue should related to what kind server you've setup. i.e. is your svn server URL like file:// or svn:// or http:// or svn+ssh://. There's a whole chapter to introduce the svn server configuration here: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.html Wish it can help you.
Re: svn Farm
On 17 October 2010 08:52, Alan Barrett a...@cequrux.com wrote: On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. --apb (Alan Barrett) The reality is if you don't trust the client, then you don't trust the client so how can you trust it to report what it supports correctly? It would be trivial to fork svn to lie and report that it only stored passwords encrypted, stick that forked client on my machine and hey presto, away I go storing my password in plaintext. I think that the best compromise would be for the SVN client to report its capabilities like the SVN 1.5+ clients do: 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 And that sorts out Nico's requirement for blocking the insecure 1.4 clienst in Redhat EL/CentOS Add a capability called keyringenabled to Subversion and now Nico will probably be much happier... but of course he doesn't trust his users so he cannot trust that they report keyringenabled correctly... but he might be pragmatic enough to accept that as a compromise. and that's probably a feature we could add in 1.6.14 with only minor effort (most of the work being deciding what the feature name should be ;-) ) -Stephen
svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate
Hi , When I checkout one svn repository,the svn return this error message,please tell me how to deal with and can check out? Thanks This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
Re: svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate
Try: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.ref.svn.c.switch http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.ref.svn.c.switchCheers / Erik 2010/10/18 周晓青 xiaoqing.zho...@alibaba-inc.com Hi , When I checkout one svn repository,the svn return this error message,please tell me how to deal with and can check out? Thanks -- This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
Re: svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate
On Oct 18, 2010, at 05:35, 周晓青 wrote: When I checkout one svn repository,the svn return this error message,please tell me how to deal with and can check out? Thanks http://svn.apache.org/viewvc/incubator/thrift/trunk/lib/java/ is a ViewVC URL; it a URL that you can call up in a web browser to look at stuff inside a Subversion repository, but it is not the URL of the repository itself, and you cannot pass that URL to a Subversion client or you will get the error message you reported. You need to find out what the project's Subversion repository URL is. In this case, it happens to be http://svn.apache.org/repos/asf/incubator/thrift/trunk/lib/java/
Implementing lightweight client over http. Where to start?
Porting the full svn client to my environment is not something I am willing to undertake myself. So as an alternative I wanted to implement some Quick Dirty interface over HTTP hopefully with a cleartext password. Is there a document that describes the http interfaces to svn server for each function? Thanks, Andrew
Re: Compiling mod_dav_svn against an installed Apache2 instance ?
On Oct 17, 2010, at 11:02, Nelson Cabral wrote: I downloaded apache 2.2.16 sources and compiled with make, but where are the binaries ? I'm not familiar with linux conventions :-/ Do binaries have an extension ? No, binaries on UNIX do not have any filename extensions. Each project is free to organize its directory structure however it likes; there isn't any standard place within the source directory where the binaries are guaranteed to be. After you've built apache, the find command on the apache source directory could help you locate where they've decided to put their binaries. Here's what I get on my system: $ find httpd-2.2.16 -name apxs httpd-2.2.16/support/apxs By the way, it turns out apxs is not a binary at all but an executable script.
Re: Encrypted repo contents
On Monday 18 October 2010 14:42:43 Ryan Schmidt wrote: On Oct 18, 2010, at 05:58, Gary wrote: I want to create a repo using online storage (think Wuala or something similar), and am pretty keen that nobody else, including the people running the storage service, can get at my code. Is it possible to ensure the repo contents are encrypted somehow? Everything I've read on the subject seems to allow encrypting the connection from clients to server, but not the repo contents as they sit on the disc. There is nothing in Subversion to encrypt the contents of the repository. You could try with a precommit hook
Re: Implementing lightweight client over http. Where to start?
On Oct 18, 2010, at 06:42, Andrew Roughan wrote: Porting the full svn client to my environment is not something I am willing to undertake myself. So as an alternative I wanted to implement some Quick Dirty interface over HTTP hopefully with a cleartext password. Is there a document that describes the http interfaces to svn server for each function? Subversion uses many other libraries to get its job done, including apr and apr-util, expat, neon or serf, sqlite and others, and Subversion is itself divided into several libraries that carry out the various tasks. I think if the Subversion developers could have might Subversion lighter, they would have, and I don't think you will be able to make any such quick and dirty client without having to reimplement most of Subversion, which, as you may know, represents ten years worth of work. What is this mysterious environment you have where Subversion does not already run? To answer your question, the Subversion HTTP interface is WebDAV, so you can read up on that.
checksum error
I have a master slave server, in US and India. They are both 1.6.12, but the slave was 1.5.7 until a few days ago. The master is at rev 5050, but the slave will only sync up to rev 5045. Every time it tries to sync 5046, I get a checksum error in the apache error_log. It says some file fails md5. In order to figure out where the corruption is, I tried using a svn client, to simply checkout that file from the master, rev 5044, 5045, 5046. Had no problem. Correct me if I'm wrong, but, if the corruption were on the server, I should have gotten the error during that operation, right? Does the svn sync slave do md5 checksums that the svn client doesn't do? If I restore the slave from backup, and re-try the sync, it consistently fails at 5045 trying 5046, and always the same file, and always the same mismatched checksum. Since we're drawing the conclusion that the corruption is in the slave, it must mean that a past rev of something was corrupted and undetected. In fact, when I upgraded from 1.5.7 to 1.6.12, I did a dump load. So it seems, if I had silently corrupted on-disk, I should have discovered the problem at that time, right? Unless perhaps ... 1.5 didn't do checksums so the 1.6 dump load has nothing from the past to verify... Does 1.6 do some new md5 checksumming that 1.5 didn't do? Anyway, I'm transferring a new fresh copy of the repo to the slave. I figure this should fix it. But I'm extremely curious how this all happened.
Re: Subversion equivalent to VSS diff for binary files
Subversion does handle binary files without any problems. In uses the property svn:mime-type on the file to mark it as a binary file, so it knows not to attempt a text merge on the file. Subversion does a good job with handling binaries. However, there is issue that makes storing binary files in Subversion problematic. Subversion really doesn't have an easy way to remove individual revisions of particular files. Normally, with text files, this isn't an issue. Text files are stored as diffs and removing a particular revision of a text file won't save a lot of room in the repository. Most people don't bother removing text revisions unless the text revision contains inappropriate or proprietary information that you don't want kept around. However, binary files are a bit different. Changing one line in a file and then compiling it may cause a cascade of changes, so the resulting difference between the previous revision of the binary and current version of the binary are quite huge. Storing a binary file as revisions in ANY revision control system takes up a great deal of space when compared with storing revisions of text. In many sites, the built objects are stored under revision control, maybe for every single build. You do this after a while, and you'll chew up a lot of disk space. To handle this, many sites have a way of identifying obsolete binary revisions and destroying them. I remember several papers in Perforce conferences on this very topic. (The idea was to remove the space hogging binary revision without destroying the revision itself. That way, you'd still see the history, but not have access to the file contents). So, the best thing to do is not to store binary files when you don't have to. Storing binaries is done for several reasons some are: 1. Not being sure that you can repeat your build process, so you want to keep the binary revision just in case. The solution to this is to create a repeatable build process, so you don't have to store the binaries. 2. Storing releases. A very common tactic, but revision control systems aren't really ideal for this anyway. Most people who need to grab the releases aren't necessarily developers, so using a revision control system to get the release they want simply adds complexity. A better way is to use a release repository system. 3. Storing third party artifacts. This is usually not a space issue since it is unlikely you'll be storing a hundred revisions of a particular third party binary. You might, maybe update a third party binary one or twice a year. The problem with this (which is a problem with every revision control system out there) is that you quickly lose the true identify of the third party revision. This happens all the time with Jar files. Is that log4j.jar revision 1.2.3 or 1.4.6? How do I know? In the end, you'll end up with a pile of unidentifiable and probably obsolete third party binaries. Considering that the whole purpose of revision control is identifying what is in your software, having a wad of unknown third party binaries isn't a great way to accomplish this task. The true solution to this is to use a release repository system. If you use Ant, it's quite simple to incorporate ivy, and once done, the developers are usually quite happy with the results. Even if you aren't working on a Java project, you should use some sort of release repository for this type of stuff. Should you ever store binary files in Subversion? Of course, but only when it is really the best way to handle the problem. If your source code includes JPGs and GIFs, or you include a Word document in your release, there isn't really an alternative, but to store the binary file. Space isn't an issue since these files are relatively small and aren't updated that frequently. (Compare a few megabytes of a Word document that you update once per month vs. storing a 1.5 gigabyte build that you produce two to three times per day). So, there are two sides to binaries in Subversion story: Yes, Subversion handles binaries just as well as other revision systems. Some say even better. Subversion knows what files are binary by using the svn:mime-type property. In fact, Subversion can, unlike many version control systems, actually distinguish between binary types, and it is possible via third party tools to actually diff binary files (like between two Word documents). No, Subversion doesn't allow easy pruning of space hogging binaries, and therefore it can cause problems in that respect. If you're using a revision control system, and now have a policy of removing obsolete binaries on a regular basis, you'll have problems continuing this with Subversion. However, if this is a problem, it's more likely due to incorrectly using your revision control system (unable to rebuild order binaries in a consistent manor, or using your version control system as a release repository). The solution would be to fix the underlying problem rather than not to use Subversion. -- David
Re: Implementing lightweight client over http. Where to start?
On 18 October 2010 12:56, Ryan Schmidt subversion-20...@ryandesign.com wrote: On Oct 18, 2010, at 06:42, Andrew Roughan wrote: Porting the full svn client to my environment is not something I am willing to undertake myself. So as an alternative I wanted to implement some Quick Dirty interface over HTTP hopefully with a cleartext password. Is there a document that describes the http interfaces to svn server for each function? Subversion uses many other libraries to get its job done, including apr and apr-util, expat, neon or serf, sqlite and others, and Subversion is itself divided into several libraries that carry out the various tasks. I think if the Subversion developers could have might Subversion lighter, they would have, and I don't think you will be able to make any such quick and dirty client without having to reimplement most of Subversion, which, as you may know, represents ten years worth of work. What is this mysterious environment you have where Subversion does not already run? To answer your question, the Subversion HTTP interface is WebDAV, so you can read up on that. That depends on what you want that client to do if all you are after is to fetch the head revision and you are not interested in modifying the repo, then you could have a fairly light client using just a http client lib if you want to check stuff back in then you might be able to get somewhere with DAV support which could be handled though http requests quite simply, but you'd be loosing out on lots of good functionality... It would be possible to get a smaller client, if you only need to support a smaller set of use-cases... -Stephen
Re: Subversion equivalent to VSS diff for binary files
(didn't read it all very very carefully; was too long for that) David Weintraub wrote on Mon, Oct 18, 2010 at 09:47:32 -0400: Text files are stored as diffs and removing a particular revision of a text file won't save a lot of room in the repository. ... However, binary files are a bit different. Changing one line in a file and then compiling it may cause a cascade of changes, so the resulting difference between the previous revision of the binary and current version of the binary are quite huge. Seems to me the solution is Don't store your binaries in Subversion. What does storing the binaries in Subversion gain? (as opposed to storing all historical binaries in FTP somewhere) In fact, Subversion can, unlike many version control systems, actually distinguish between binary types [...]. What are you referring to?
Re: can not delete folder because lock
On Oct 18, 2010, at 09:14, netvampire.tw wrote: I use Subversion 1.6.13 recently, we want to delete a folder but fail.The error message said there is a file name is locked by someone. try to release lock or steal lock. But the file already didn't exist. So we can not lock it. what happened to us? How could we do? thanks.~ Yes, there is a bug or unexpected feature that Subversion allows locked files to be deleted but does not remove the locks. This was discussed once before, here: http://old.nabble.com/Zombie-files-prevent-me-from-re-adding-deleted-file-td20210870.html The above thread references a contributed script you can use to clean up these forgotten locks.
Re: Subversion equivalent to VSS diff for binary files
On 10/18/2010 9:25 AM, Daniel Shahaf wrote: (didn't read it all very very carefully; was too long for that) David Weintraub wrote on Mon, Oct 18, 2010 at 09:47:32 -0400: Text files are stored as diffs and removing a particular revision of a text file won't save a lot of room in the repository. ... However, binary files are a bit different. Changing one line in a file and then compiling it may cause a cascade of changes, so the resulting difference between the previous revision of the binary and current version of the binary are quite huge. Seems to me the solution is Don't store your binaries in Subversion. Or at least binaries that can be rebuilt exactly from the version-controlled source. What does storing the binaries in Subversion gain? (as opposed to storing all historical binaries in FTP somewhere) If you put them somewhere else you have to re-invent conventions to describe (in both directions) where to find the source/binaries that go together - and perhaps write your own authentication/permissioning mechanism to enforce them. The main disadvantage of putting them back in subversion is that they will most likely be obsolete after a few new builds and there's no handy way to remove them or reclaim the space they consume. -- Les Mikesell lesmikes...@gmail.com
UTF8 BOM Merge
May be i will be better to post mail with better subj. then use older one, so I will try. Hi all, Another problem with UTF, now it is problem when merging 2 files which are UTF8 (BOM) The file on local HDD is still UTF8, but the file from repository is ANSI :-() IdFromKodGenerator.cs.merge-left.r43343 - ANSI but in trunk (from I'm doing merge is UTF-8) IdFromKodGenerator.cs.merge-right.r43356 - branch into I'm merging is UTF-8. Can you help me with that? A.
Re: Subversion equivalent to VSS diff for binary files
On Mon, Oct 18, 2010 at 10:25 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: Seems to me the solution is Don't store your binaries in Subversion. It all depends upon the binary file type and why you're storing it. If your build uses GIFs and JPGs, you need to store binary files on Subversion. And, Subversion has no problems with this. Another example of storing binaries in Subversion? In my last job, our help system used Robohelp which produced a wad of HTML files from a Word document. Robohelp had to run on a PC while our builds were done on Linux. Originally, we were attempting to store the resulting HTML (mainly text) files on Subversion, but because Robohelp would completely rebuild everything even with the most minor change, it meant that the techwriters had to delete and add files hundreds of files in Subversion with even the most minor technical document changes. I decided to simply have the techwriters zip up all the HTML stuff into a single ZIP file and store that in Subversion. It made their lives simpler, and it meant that svn log only showed a single file change whenever the help was updated. That ZIP file was binary, but in this case, it was worth storing it inside our repository. But, storing your build output in Subversion? I'd argue it would be questionable in ANY version control system simply because there are better tools that can be used for this purpose. For example, we use Hudson as our continuous build server. Our Hudson process not only creates a new release with each and every check-in (running Unit and Coverage tests), but it also stores the resulting build. We setup Hudson to automatically delete most builds after a certain period of time unless we mark them for QA or production. And, as I just mentioned, we even mark builds in Hudson with their QA and Production status. QA and System admins have no problem locating the correct build to use. You can even configure Hudson to use the results of Project A's build in Project B. And, you can setup Hudson to automatically build Project B whenever Project A rebuilds. So, by using Hudson, there's no need to purge your revision control system of obsolete binaries, your non-developers don't have to use a revision control system just to get the files they want, and something like Hudson automatically handles tracking build status for you. By the way, my actual preference for a release Repository is either Nexus or Artifactory. They provide a well documented (and open way) way of doing the task which means I'm not tool dependent. Yes, they're Maven repositories, but I find them just as effective for non-Maven projects. -- David Weintraub qazw...@gmail.com
Re: Implementing lightweight client over http. Where to start?
On Mon, Oct 18, 2010 at 12:56 PM, Ryan Schmidt subversion-20...@ryandesign.com wrote: What is this mysterious environment you have where Subversion does not already run? Apple IIgs with a 1Mz 65816 processor (or faster with accelerators and emulators). Yes there is a C compiler, but abysmal performance is likely to be an issue. On Mon, Oct 18, 2010 at 2:51 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That depends on what you want that client to do I don't intend to fully implement all functionality. I want to be able to checkout and commit. I will look into WebDav support a bit more. I've read a few more webdav notes and found the references to RFCs. Thanks, Andrew
Re: Implementing lightweight client over http. Where to start?
On Oct 18, 2010, at 10:47, Andrew Roughan wrote: On Mon, Oct 18, 2010 at 12:56 PM, Ryan Schmidt wrote: What is this mysterious environment you have where Subversion does not already run? Apple IIgs with a 1Mz 65816 processor (or faster with accelerators and emulators). Yes there is a C compiler, but abysmal performance is likely to be an issue. Applause! :) Best of luck with this project. Perhaps you can make use of some existing work: http://www.whatisthe2gs.apple2.org.za/subversion/ More seriously, since the Apple II operating system isn't related to UNIX it may be difficult to get APR ported to it, but that would be the library to start with.
Having a path name after specifying repository location
Hi, My repository path is /var/lib/svn for the SVN server. However I encountered a unique situation as follow: The following works: #svnadmin create /var/lib/svn/projectA From a svn client: #svn co http://svnserver/svn/projectA projectA However the following does NOT work: #mkdir /var/lib/svn/projectB/ #sudo svnadmin create /var/lib/svn/projectB/partA #sudo svnadmin create /var/lib/svn/projectB/partB From a svn client: #svn co http://svnserver/svn/projectB/partA partB Is it true that all the directories directly under /var/lib/svn/ should be an *actual* repository? Can't we have some pathname like ProjectB under /var/lib/svn/ and then have repositories (like PartA and PartB) under it without changing the root path of the repository which is /var/lib/svn? How do you overcome this situation? I want PartA and PartB to be separate SVN repository but I do not want to place them under /var/lib/svn/ directory because they beloing to ProjectB and in future other projects like ProjectD could have PartA and PartB in the same manner. Thanks.
Re: Having a path name after specifying repository location
oops...I had a typo: However the following does NOT work: #mkdir /var/lib/svn/projectB/ #sudo svnadmin create /var/lib/svn/projectB/partA #sudo svnadmin create /var/lib/svn/projectB/partB From a svn client: #svn co http://svnserver/svn/projectB/partA partB However the following does NOT work: #mkdir /var/lib/svn/projectB/ #sudo svnadmin create /var/lib/svn/projectB/partA #sudo svnadmin create /var/lib/svn/projectB/partB From a svn client: #svn co http://svnserver/svn/projectB/partA partA I get the error message: SVN: Could not open the requested filesystem.
Re: svn Farm
On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Add a capability called keyringenabled to Subversion and now Nico will probably be much happier... but of course he doesn't trust his users so he cannot trust that they report keyringenabled correctly... but he might be pragmatic enough to accept that as a compromise. Now, now. Don't put words in my mouth. I'm concerned about obvious and possible and documented attack vectorrs: passwords in cleartext are one of them. Eventually, any idiot can write a script that stores passwords in clear-text to mishandle local passwords or passphrase protected keys, but putting the capability in as the default behavior is extremely poor practice and should not be supported by default configuration or behavior. I don't think that keyring enabled is sufficient. A protocol shift that *requires* a better protected password and blocks the currently unsecured local password storage access would be interesting, I thought the gpg-agent changes would do that, but Stefan pointed out the flaws, dang it. svn+ssh actually works reasonably well: it just doesn't suppor the use my normal login password approach to managing user access. and that's probably a feature we could add in 1.6.14 with only minor effort (most of the work being deciding what the feature name should be ;-) ) -Stephen If it could require the client to actually *use* the keyring, I could see it. How would we support that for TortoiseSVN clients?
Re: can not delete folder because lock
It works fine.I use Tortoisesvn did it. Thanks. So the bug didn't fix until now? - 原始信件 寄件者： Ryan Schmidt subversion-20...@ryandesign.com 收件者： netvampire.tw netvampire...@yahoo.com.tw 副 本： users@subversion.apache.org 寄件日期： 2010/10/18 (一) 10:29:23 PM 主 旨： Re: can not delete folder because lock On Oct 18, 2010, at 09:14, netvampire.tw wrote: I use Subversion 1.6.13 recently, we want to delete a folder but fail.The error message said there is a file name is locked by someone. try to release lock or steal lock. But the file already didn't exist. So we can not lock it. what happened to us? How could we do? thanks.~ Yes, there is a bug or unexpected feature that Subversion allows locked files to be deleted but does not remove the locks. This was discussed once before, here: http://old.nabble.com/Zombie-files-prevent-me-from-re-adding-deleted-file-td20210870.html The above thread references a contributed script you can use to clean up these forgotten locks.
Users cannot reliably view SVN log messages remotely
Hi all, I've got a distant user who cannot reliably view the SVN log messages Using TortoiseSVN. If he 'refreshes', he can view the SVN log messages fine. Also, checkouts work fine. Other users at his (distant) site seem to have the same issue, but I can't reproduce the issue here and haven't heard of similar issues from other sites. We're using Apache, and I did notice that the Apache logs occasionally shows the below errors and wonder if there is a known explanation or solution: Provider encountered an error while streaming a REPORT response. [500, #0] A failure occurred while driving the update report editor [500, #103] Error writing base64 data: Software caused connection abort [500, #103] I've checked the Subversion FAQ, and think the fix there does not apply since my users are on Windows. Does anyone know how to resolve these errors? I'm suspecting a network issue, so my next thing to try is to increase the Apache timeout in httpd.conf. My hunch is that this won't solve the issue, so if anyone has additional ideas to try I'd really appreciate it. Thanks! Shaun
RE: Users cannot reliably view SVN log messages remotely
I've checked the Subversion FAQ, and think the fix there does not apply since my users are on Windows. Does anyone know how to resolve these (...Sent this out too quickly... I meant to say:) We're not serving from a MacOS X 10.4 machine, so I don't think the FAQ applies here.
