Re: Error connecting to an Apache svn server remotely
2011/5/15 Kenny Q. Zhu : > I’m out of ideas! Please help!! 1. Configure HTTPS. It won't be mangled at proxies, and it will protect your password during transmission. 2. Are you sure that http://www.xxx.edu/mysvn is a correct address? Are you able to browse repository at that address directly with a web browser, e.g. Firefox? Best regards, Konstantin Kolinko
RE: Error connecting to an Apache svn server remotely
Thanks for your reply. Yes I can browse the svn on a web browser from outside the campus network. So this is really strange. Kenny -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Sunday, May 15, 2011 6:54 PM To: Kenny Q. Zhu Cc: users@subversion.apache.org Subject: Re: Error connecting to an Apache svn server remotely 2011/5/15 Kenny Q. Zhu : > I'm out of ideas! Please help!! 1. Configure HTTPS. It won't be mangled at proxies, and it will protect your password during transmission. 2. Are you sure that http://www.xxx.edu/mysvn is a correct address? Are you able to browse repository at that address directly with a web browser, e.g. Firefox? Best regards, Konstantin Kolinko
Howto: Mercurial to Subversion migration
Hello I am commiter in the Apache Wave project which was accepted into the Apache incubator. We already migrated our issues from the googlecode to the Jira and the next step is migration of the source code into the Apache SVN from Mercurial. I tried to google for information on mercurial to svn migration but couldn't find any simple (or even any working) solution. It would be a great help to our migration effort if someone from the Subversion team can advice on the best way to handle this. Thanks Yuri Zelikov
'svn info' alternative?
Is there something outside the svn application, a ‘working directory only’ version of svn info, (svninfo?), that we could use to obtain local working directory “info”. This standalone would not require the security demanded by svn proper. Thank you.
Re: 'svn info' alternative?
Have you looked at svnversion ? That is what it does. Sent from my iPhone On May 15, 2011, at 12:17 PM, cate wrote: > Is there something outside the svn application, a ‘working directory > only’ version of svn info, (svninfo?), that we could use to obtain > local working directory “info”. This standalone would not require the > security demanded by svn proper. > Thank you.
Re: Merge, undetected tree conflict when source tree moves directory
(perhaps we should move to the dev-list? i'm not expert of this, i'll follow the thread) I've removed code references cause i'm asking a few more "conceptual" questions here, to understand if we can simplify the detection avoiding the diff. Fire me if i become trivial. On Wed, May 4, 2011 at 12:03 PM, Stefan Sperling wrote: > > > To determine whether the deletion of a directory causes a tree conflict, > we need to know whether the directory that has been deleted in the merge > source had the same content as the corresponding deleted directory in > the merge target. If it did, there is no conflict so it can be safely > deleted. If it did not, a tree conflict needs to be flagged. > > The problems we were facing are as follows: > > 1) At present, it is impossible to tell apart a rename from a deletion. You seem to be concerned mostly about reliably detecting the following > situations: > incoming delete vs. local edit > incoming delete vs. local rename > incoming rename vs. local rename > incoming rename vs. local delete > It helps to keep in mind that all of the following cases look the same > to Subversion at the moment: > incoming delete vs. local rename > incoming rename vs. local delete > incoming rename vs. local rename > incoming delete vs. local delete > The last case is not really a conflict but needs to be flagged as such > because it looks the same as the former three possibilities. > So you would still have to check each reported tree conflict for validity. > This behaviour already applies for files in 1.6.x though, so it's a > problem that isn't unique to directories. It is nevertheless annoying. > But maybe less annoying than the current situation. > Said that rename=deletion++, i'd concentrate only on the following 2: 1.a) incoming delete vs local delete: i'd consider this a normal conflict: both trees could have moved that dir (that would look exactly the same before deletion): in this case, we should help to avoid duplicates. 1.b) incoming delete vs local edit: could we try something simplier than a tree-compare? I imagine (but i haven't studied apis, yet) that "checking for commits in a working copy tree" be cheaper than tree-comparing with the repository tree; 99% of times local commits actually mean the "local edit" we were searching, don't they? (I can only see a false positive if a file or a dir is first modified and then restored exactly equals in the wc branch) So we could check the following "has any local edit (commit) happened in the destination tree since last time they were OK?" (see below for "OK" definition) NO) ok to delete YES) tree conflict OK: branch copy/creation; or last successfull merge (i.e. a commit in the destination/wc tree) in which they had been successfully integrated, even if different/modified. next days i'll start to have a look at the code; if there are no good/feasible ideas above, i also think tree compare is the clean solution. 2) Comparing a mixed-revision working copy to a tree in the repository > (which is always at a single revision) can produce spurious differences. > However, as of 1.7, merges into mixed-revision working copies are > disallowed > by default. So this problem is now less of a concern than it used to be. > ok to leave this out from the rest of the thread 3) Comparing a local tree to some tree in the repository usually implies > quite a bit of network and server-side processing overhead. It will be > quite noticeable in most environments. This comparison would need to be > performed for every incoming deletion of a directory. It's already being > done > for files but comparing entire directory trees will in general take longer. > Having some kind of optimisation in place for this purpose would be good. > However, I'd favour correctness over performance. > > 4) We need the above comparison to be reliable. I don't remember the > details, but I think we found problems with the diff implementation > while trying to compare a working copy tree to a repository tree. > These problems may have been due to corner-case bugs since this kind > of operation is rarely tested in practice. But it might also have been > due to the mixed-revision working copy problem, which we can now ignore. > There is some research left to be done here. > I'm for reliability, too. I'd only (eventually) welcome some false positives in favour of big optimization (waiting for the real rework in 1.8).
Fwd: Howto: Mercurial to Subversion migration
[Accidentally sent privately by accident, meant to send to list.] -- Forwarded message -- From: Nico Kadel-Garcia Date: Sun, May 15, 2011 at 1:02 PM Subject: Re: Howto: Mercurial to Subversion migration To: Yuri Z On Sun, May 15, 2011 at 11:45 AM, Yuri Z wrote: > Hello > I am commiter in the Apache Wave project which was accepted into the Apache > incubator. We already migrated our issues from the googlecode to the Jira > and the next step is migration of the source code into the Apache SVN from > Mercurial. I tried to google for information on mercurial to svn migration > but couldn't find any simple (or even any working) solution. It would be a > great help to our migration effort if someone from the Subversion team can > advice on the best way to handle this. > Thanks > Yuri Zelikov I'm not a member of the "team", just an experienced user. I was faced with a similar project, recently, with git, and said "don't make me hurt you". The only way I know of is to do an export of your current codebase, and import it into SVN. The same is true for git. tools to convert svn to other, more distributed systems are common place. There are compelling reasons that repository conversion is awkward, much like converting bread back into wheat. You might be able to do something useful with "hgsvn", linking a working mercurial copy writing scripts to step through the mercurial updates and committing them to a Subversion trunk. Complete integration of all available mercurial or git properties to Subversion, including unweaving interwoven and multiply sourced component histories, though? It's like turning a sweater back into a sheep's fleece, it's messy, and the sheep will be unhappy.
Re: svn log --diff --depth=empty
> > Would it be possible for svn log --diff to accept the same --depth
> > argument that svn diff does? An svn client I built from trunk last
> > week does not recognize --depth in conjuction with svn log --diff
>
> It now does as of r1100830. Let me know if it works as expected.
> Thanks for the suggestion!
Thanks, this does work the way I expected.
The svn help log output includes the following fragment; it might be
good for the --depth help text to explicitly explain that it only
affects --diff output, and requires the --diff option, and it might be
best to list --depth after --diff.
--depth ARG : limit operation by depth ARG ('empty', 'files',
'immediates', or 'infinity')
--diff : produce diff output
--diff-cmd ARG : use ARG as diff command
RE: SVN files content Type
Hi Daniel/Ryan Thanks. I understood that the mime content-types are not sending to the client from the server's mime.types file , intead it takes from the files which have subversion mime-type property set. I am unable to configure this to bypass to apache mime.types file. Here my requirement is that whoever accessing the repository through web browser must get the mime content-type from the apache file conf/mime.types and not from the svn:property. Please help on this. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, May 10, 2011 3:17 PM To: Ryan Schmidt Cc: D, Dinoj; users@subversion.apache.org Subject: Re: SVN files content Type Ryan Schmidt wrote on Tue, May 10, 2011 at 02:41:25 -0500: > > On May 10, 2011, at 02:24, D, Dinoj wrote: > > > Thanks for your prompt response. The content type should be worked only > > while accessing the files through web browser.The problem here we are > > facing is that while accessing the files through web browser the > > extensions .docx, .pptx, .xlsx are opening as zip files. The > > configuration for SVN in apache is > > > > > > DAV svn > > SVNPath /repo/Test > > > > > > > > > > In which can we point the content to conf/mime.types file using > > > > TypesConfig conf/mime.types > > > > Or is there any methods like > > > > ModMimeUsePathInfo on > > > > Or > > AddType image/gif .gif or if any? > > No. Set the svn:mime-type property to the correct value on these files. > If nothing else, it ought to be technically possible to throw an HTTP proxy that detects file extensions on GET requests to the mod_dav_svn -controlled location and rewrites the Content-Type for those. So, I'd expect there to be a way to configure httpd to bypass mod_dav_svn's reported MIME types. > >
AW: Detect incompatible (future) workingcopy format.
Hi, Daniel, > Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Markus Schaber wrote on Fri, May 13, 2011 at 11:20:11 +0200: > > What is the safest future-compatible way to check for an incompatible > > / unknown working copy format which was written by a future subversion > > version? (e. G. WC-NG by SVN 1.7?) > > > > My idea was to run status with depth=empty on the workingcopy root, > > and check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code. > > What about SVN_ERR_WC_UPGRADE_REQUIRED? I did read this error code as "the working copy is in an known, but older format, I need and can perform an explicit upgrade" - just the opposite of what I need. And it is marked as /** @since New in 1.7. */, so 1.6.16 is unlikely to raise it. > > Is there a function specifically designed for this purpose? > > If there isn't, it seems like a good idea to have one, in order for the > library to clearly communicate "I cannot perform of basic operations> on this working copy unless you upgrade it". [> ] 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: .svn/entries format
Hi, Cate, > Von: Cate Bekensail [mailto:catebekens...@yahoo.com] [> ] > We need to obtain information that would normally be provided by 'svn > info'. The page, the apache user, does not have access to this program, > but he can read the project’s .svn/entries file. We can guess at the > information needed but was wondering if the format is published. Strictly > an ro affair. (saw a previous nanny post) The format is published in the form that it is documented in the source dowload. But it is not intented to be read directly by 3rd party applications, its format can change in incompatible ways between SVN releases. > The env/server is Linux/apache. There are a hundred ways to do this, but > allowing perl to read this file seems easiest. Isn't there a perl-svn module somewhere on cpan? > Admin will not allow apache user access to svn. Not even a local installation (chroot or similar)? > Also, is there something outside the svn application, a ‘working directory > only’ version of svn info, (svninfo?), that we could use to obtain local > working directory “info”. This would not require the security demanded by > svn proper and would save us from having to read this file. You could also write a small C program linking statically against the subversion libraries... 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: Howto: Mercurial to Subversion migration
> I am commiter in the Apache Wave project which was accepted > into the Apache incubator. We already migrated our issues > from the googlecode to the Jira and the next step is > migration of the source code into the Apache SVN from > Mercurial. I tried to google for information on mercurial to > svn migration but couldn't find any simple (or even any > working) solution. It would be a great help to our migration > effort if someone from the Subversion team can advice on the > best way to handle this. Mercurial comes bundled with the ConvertExtension. This extension accepts a Mercurial repo as source and SVN as destination. Having said that, I have never tried it, but you might give it a shot. Details are here: http://mercurial.selenic.com/wiki/ConvertExtension Best regards/Freundliche Grüsse Wenzel Metromec AG Andreas Tscharner -- Andreas Tscharner, Development Wenzel Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch CT-Dienstleistungen neu bei Wenzel Metromec = Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell? Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren? Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen! Testen Sie uns und unsere neue WENZEL exaCT Anlage. Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf. mailto:c...@metromec.ch?subject=CT-Dienstleistungen
Re: SVN files content Type
On May 16, 2011, at 00:42, D, Dinoj wrote: > Hi Daniel/Ryan > > Thanks. I understood that the mime content-types are not sending to the > client from the server's mime.types file , intead it takes from the > files which have subversion mime-type property set. I am unable to > configure this to bypass to apache mime.types file. That's correct. > Here my requirement > is that whoever accessing the repository through web browser must get > the mime content-type from the apache file conf/mime.types and not from > the svn:property. Please help on this. There's no way to configure Subversion to do that. As I already suggested, consider having a server-side post-commit hook that updates a server-side working copy of a relevant part of your repository, and point your apache at that working copy. Then, when users want to access this site, instruct users to use that other URL, not the repository URL. As a concrete example: Consider you have an HTML page in a project in a repository accessible here: http://www.example.com/svn/project1/trunk/folder/index.html You haven't been using svn:mime-type, so users who view this URL in a web browser will see the source of the document, instead of the page rendered as HTML which is what you want. Imagine your repository is on the server at /var/svn, and that you have a document root at /var/www used for everything at http://www.example.com/ other than the /svn directory, like this: ServerName www.example.com DocumentRoot /var/www DAV svn SVNPath /var/svn http://www.example.com/svn/project1/trunk project1 Now you can access that same HTML file from above at: http://www.example.com/test/project1/folder/index.html And now it will use the MIME types from the Apache configuration. Now, you install a post-commit hook script in the repository which basically does: svn up /var/www/test/* This way, every time anyone commits anything to the repository, the test directories will be updated as well. Updating "*" will be slow, so you can optimize this further if you like to just update the thing that was just committed.
