Re: Does svn merge --reintegrate ^URL syntax really work ?
Thank you Erik, 1. I think I got the cause: I use Subversion in windows system, it's a little different to linux/unix system: The ^ character is a special character in command prompt window or batch file. the ^ character and it's following characters MUST be quoted: E:\Incoming\svntest\calc\branches\new-branchsvn list ^/ svn: '\' is not a working copy E:\Incoming\svntest\calc\branches\new-branchsvn list ^/ calc/ paint/ tools/ 2. But, beause ^ means the URL of the repository's root directory”, why svn-book use ^/trunk instead of ^/calc/trunk ? The repository layout ( http://svnbook.red-bean.com/nightly/en/images/ch04dia2.png ) in svn-book is like the following: E:\Incoming\svntest\calc\branches\new-branchsvn list ^/ -R calc/ calc/branches/ calc/branches/new-branch/ calc/branches/new-branch/Makefile.txt calc/branches/new-branch/button.c calc/branches/new-branch/int.c calc/trunk/ calc/trunk/Makefile.txt calc/trunk/button.c calc/trunk/int.c svn-book-1.5-final-r3305: -- $ svn merge http://svn.example.com/repos/calc/trunk --- Merging r345 through r356 into '.': U button.c U integer.c svn-book-1.6-nightly-r3776: -- $ svn merge ^/trunk --- Merging r357 through r380 into '.': Uinteger.c UMakefile AREADME Erik Andersson-3 wrote: 10 sep 2010 kl. 04:16 skrev LiuYan 刘研 lovet...@21cn.com: Hi, I'm learning Subversion via svn-book, I encountered a problem in section Reintegrating a Branch: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate In this section, it use the following syntax: svn merge --reintegrate ^/branches/my-calc-branch But when I try it, it always report an error: E:\Incoming\svntest\calc\trunksvn merge ^../branches/my-calc-branch --reintegrate Don't mix ^ with .. svn: 不能打开文件“file:///E:/SVNRepository/svntest/calc/branches/.svn/entries”: 文件名、目录名或卷标语法不正确。 (can't open file file:///E:/SVNRepository/svntest/calc/branches/.svn/entries: File name、Directory name or volume syntax incorrect) Then I try full URL syntax (which is in svn-book-1.5), it works. E:\Incoming\svntest\calc\trunksvn merge --reintegrate file:///E:/SVNRepository/svntest/calc/branches/my-calc-branch --- 正在合并版本库 URL 之间的差异到 “.”： Uint.c U . I search the svn log of svn-book, I found this syntax was changed in svn-book-r3383: Modify ch01 and ch04 to use new ^ URL syntax. (Issue #23.) So, does svn merge --reintegrate ^URL syntax really work ? -- View this message in context: http://old.nabble.com/Does-svn-merge---reintegrate-%5EURL-syntax-really-work---tp29673121p29673121.html Sent from the Subversion Users mailing list archive at Nabble.com. -- View this message in context: http://old.nabble.com/Does-svn-merge---reintegrate-%5EURL-syntax-really-work---tp29673121p29674288.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Does svn merge --reintegrate ^URL syntax really work ?
LiuYan 刘研 wrote on Fri, Sep 10, 2010 at 00:19:54 -0700: Thank you Erik, 1. I think I got the cause: I use Subversion in windows system, it's a little different to linux/unix system: The ^ character is a special character in command prompt window or batch file. the ^ character and it's following characters MUST be quoted: Or doubled: ^^/trunk . And this is documented. E:\Incoming\svntest\calc\branches\new-branchsvn list ^/ svn: '\' is not a working copy E:\Incoming\svntest\calc\branches\new-branchsvn list ^/ calc/ paint/ tools/ 2. But, beause ^ means the URL of the repository's root directory”, why svn-book use ^/trunk instead of ^/calc/trunk ? It seems the book is inconsistent on whether 'calc' is a repository or a directory inside a repository. Could you report this to the svnbook list please?
Auto props
Hi all, Is it possible to set up enable-auto-props = yes and eon styles on server side, or this is possible only on client side? I want to set up this on server side, because I do not want to change configs on all clients and I want to be sure, that all clients will set up autoprops correctly for certain files. Than you A.
Re: Update and Status in large working copy causes Windows to hang
On Fri, Sep 10, 2010 at 10:14 AM, ullrich.j...@elektrobit.com wrote: Hi. Now I'm getting bitten by this. -Original Message- From: Justin Johnson [mailto:jus...@honesthacker.com] Sent: Monday, October 26, 2009 9:39 PM Subject: Re: Update and Status in large working copy causes Windows to hang [...] Interesting, none the less. Thank you. I was still planning on trying to get Symantec AV disabled for testing purposes. Just posting my progress. :-) I'll post again with my results of that test, assuming I can convince someone to let me. In my case, disabling OfficeScan didn't help. I have the funny issue that two machines that are nearly identical except for the processor behave differently. Machine A: Intel Core2 Quad, 4 GB memory, running XP SP3: works. Machine B: Intel i7, 4 GB memory, running XP SP3: gets the issue with insufficient system resources. Findings we had: TortoiseSVN works on both machines. (1.6.8, svn libs 1.6.11) Command line svn client creates the issue on machine B, not on machine A. Version of the command line client: 1.6.12, was also tested with 1.6.1 Disabling hyperthreading on machine B has no effect. Disabling TurboBoost on machine B has no effect. It’s not a memory problem – the machine did not run out of memory, according to the windows performance counters. Running vmware player on machine A, svn update crashes on the host, works on the guest. Windows doesn’t quite hang, when the screen locks, you can still try to log on as Administrator, which logs off the subversion user and causes the machine to recover. I’m running out of ideas what else to try to get it running. Versions: APR 1.3.9 APR-util 1.3.9 APR-ICONV 1.2.1 Neon 0.28.6 Berkeley DB 4.4.20 OpenSSL 0.9.8o ZLib 1.2.3 Apache 2.2.15 Python 2.6 libintl 0.14.1 (patched) Ruby 1.8.6 Cyrus SASL 2.1.22 serf 0.3.0 sqlite 3.6.22 The compiled command line binary was downloaded from http://alagazam.net/ Some quick questions from the hip: - What kind of disks are the working copies located on for machine A and B? Locally or remotely? - For A and B: are they 32-bit or 64-bit? - How big is the working copy we're talking about? Can you give an idea of the number of directories, the number of files, and the total disk space (excluding .svn dirs)? Cheers, -- Johan
Re: Auto props
2010/9/10 Vojáček Aleš avoja...@fblgroup.cz: Hi all, Is it possible to set up enable-auto-props = yes and eon styles on server side, or this is possible only on client side? I want to set up this on server side, because I do not want to change configs on all clients and I want to be sure, that all clients will set up autoprops correctly for certain files. Currently that's not possible with SVN. But there is light at the end of the tunnel :-). See the following entry from the roadmap (http://subversion.apache.org/roadmap.html): Summer 2011 | Release 1.8.0 | repository-dictated config;... Gut feeling tells me that projected release date is probably not realistic (but maybe the devs can comment more on that). I expect it to be several months or up to half a year later. But that's just my personal guess. Cheers, -- Johan
Re: Checkout exclude pattern
On Fri, Sep 10, 2010 at 2:05 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: So, you want a way to do svn up --set-depth=exclude $file at checkout time? I think the desired behavior is not related to set-depth. something like: svn [up,co] --exclude pattern (reg-exp?) so you could also use set-depth, if relevant. I'm +1 on it
Re: Auto props
Please reply to the list as well, and not only to me (usually by using the Reply All button). Also, please don't top-post on this list (i.e. put your reply below the text you're replying to, not above it). Now, see below :). 2010/9/10 Vojáček Aleš avoja...@fblgroup.cz: Thank you for fast reply. So I have to create pre-commit hook which will Cheb this for me :-( And set up tsvn property which will help to clients which using TortoiseSVN clients. Do you mean a pre-commit hook that will change the properties of the file being committed on the fly? That's not possible from a pre-commit hook (will corrupt the working copy of the user that's committing). It's theoretically possible from a post-commit hook in an additional commit, but that is highly discouraged. For one thing, you must be extremely careful to avoid certain race conditions or infinite loops. And apart from that, there's the unavoidable problem that the client's working copy is immediately out-of-date after he commits (because of the additional commit from the post-commit hook). The usual approach is: - Create a standard client-side config file with the correct auto-props settings, put it on a network share and educate your developers on where they can find it and where to put it. - Set up a pre-commit hook that blocks commits that do not have the correct properties, and returns an error message telling that they need to install the standard config file, which they can find on ... This question comes up regularly on this list, so you may want to search the archives a bit for more info. (also, some people have created and posted to this list some very useful/powerful pre-commit hooks, which can be easily configured to define the properties that are required for certain file extensions etc.) Cheers, -- Johan
RE: svn:mergeinfo property question...
I recently upgraded a subversion server from 1.4.x to 1.6.6 as the old server died an unrecoverable death the 1.6.6 server was loaded via backups from dump files. Now I am getting ready to re-integrate some branches back to their trunk, and decided to try out the svn merge tracking functionality; while I have access to a 1.6.12 client) my primary working copies are on a system that only has access to a 1.5.1 client. So the basic setup: subversion server: 1.6.6 subversion client: 1.5.1 However, when I went to follow the svn redbook's re-integration steps[1], I got a series of entries that had their svn:mergeinfo property deleted. Being new to this functionality, I tried googling it - but didn't find anything that seemed to result in a yes this is okay and harmless or there's a problem; the best I found was what seems like an unfinished thread[2]. Unlike that thread, since I essentially did the dump/load upgrade path the server repository data should be fully upgraded; also, this is the first merge on these branches since the upgrade. Now if it's the case that I shouldn't be trying to use the re- integration for this branch, okay - I can do it the old way to close out the branch and then start using this new functionality on new branches; but if I can, I'd like to take advantage of this feature. Finally, all branches were made from the same 'folder level' - i.e. I explicitly branch/merge at an individual project's level - e.g. /project/trunk - /project/branches/branch - even when working with projects that are svn:external's to another project, even if I do normal work inside the svn:external - all branching/merging is done on its own working copy from the project's namespaces. So - (i) I am correct to use this feature on this branch _now_? Or do I need to close out the branch first and then use it on future branches? And (ii) is the fact that its deleting svn:mergeinfo data okay? Or is there something else I need to do? TIA, frankly... 1.5.1 has many merging bugs in it. I would suggest you upgrade the client to the last 1.5 release or the current 1.6 release. That said... I'm not sure you can just reintegrate a branch that existed before merge tracking. If you do you have to make sure to do record only merges from trunk into branch. To reintegrate the branch 100% of the trunk code must have been merged to the branch... (assuming you are reintegrating to trunk.) Yes, it is possible during a merge that mergeinfo is removed. Google for mergeinfo elision. Druing a merge svn will ellide any merge info of child nodes where all the info will reside in a parent node. BOb
Re: svn:mergeinfo property question...
- Original Message From: Bob Archer bob.arc...@amsi.com frankly... 1.5.1 has many merging bugs in it. I would suggest you upgrade the client to the last 1.5 release or the current 1.6 release. As much as I would like to be able to use a 1.6 client on the system - I can only get 1.5.1 on Kubuntu 8.04 TLS, and that requires using back-ports to do so; otherwise, I'm still limited to 1.4 on that system. So I still need to be able to do the work on that system. Sadly, the backports only has 1.5.1 and nothing newer. I might setup a Kubuntu 10.04 TLS VM do so some work with, but the 8.04 TLS has the environment I need to generate builds from for the time being, so 1.5.1 and 1.4 are sadly with me to stay for a while. That said... I'm not sure you can just reintegrate a branch that existed before merge tracking. If you do you have to make sure to do record only merges from trunk into branch. To reintegrate the branch 100% of the trunk code must have been merged to the branch... (assuming you are reintegrating to trunk.) Yes, it is possible during a merge that mergeinfo is removed. Google for mergeinfo elision. Druing a merge svn will ellide any merge info of child nodes where all the info will reside in a parent node. Thanks. The article Subversion 1.5 Mergeinfo - Understanding the Internals[1] had some really good information, and the section on elision provides some good insight into what is going on. To Quote: In other words, removing the subtree's mergeinfo is safe to do since, if the subtree's mergeinfo is equivalent to its nearest parent with explicit mergeinfo, then the mergeinfo the subtree inherits from that parent is already sufficient to describe the merges to the subtree. It's probably becoming clear now that mergeinfo inheritance and elision are just two ways of looking at the same thing: Inhertance is mergeinfo sliding down the tree from parent to child, elision is mergeinfo sliding up the tree from child to parent. So, the removal is simply b/c it matches trunk and has no other merges to worry about if I understand it correctly, in which case - it's perfectly safe and sane to do. Please correct me if I'm wrong. Ben [1] http://www.collab.net/community/subversion/articles/merge-info.html
Re: Checkout exclude pattern
Cool, that hadn't occured to me. That could mean that no structural changes are required to the .svn format -- only a code change to the checkout logic to preemptively create the exclude entries. I'm not sure how it would handle the case where someone else adds new files which match my pattern, for which no svn_depth_exclude entry yet exists. Ideas? I think under the hood, such a --exclude option would be implemented by setting the depth of the files-matching-the-pattern to svn_depth_exclude. So I'm asking if the desired feature is to be able to set that depth at checkout time, before the files are fetched even once.
Hook Script Examples
My old subversion server had a hookscript to deny commits unless there was a log message. I'd like to setup the same functionality on the new subversion server too. I already got my hook-scripts in place, but... In the process, I came across the following README files: http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/README http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/README both of which references the old tigris.org site: http://subversion.tigris.org/tools_contrib.htmlHoweve, the page is no longer available, and I can't find it on the new apache.org site either. Is this page just simply no longer going to be available? Or is there somewhere else for this stuff now? Ben
RES: Checkout exclude pattern
I'm also +1 to this feature. I understand that svn_depth_exclude should be associated to a checked out folder and set differently to other folders to build local working copy custom structure. A svn_depth_exclude_pattern set on checkout could help deciding which value use on svn_depth_exclude for other folders found when checking out. So, if the desired working copy structure follows a excluding logic, it will be automatically built on a single command. The update command should also check the same local svn_depth_exclude_pattern to decide which value to use for svn_depth_exclude for each new folder added by other users. Another parameter could be used for setting default svn_depth_exclude_pattern saved as a folder property on the repository, so that any checkout that doesn't specify a custom pattern will use this default custom exclusion pattern for the folder. Patterns set locally prevails over repository patterns. An include pattern can prevail over the exclude pattern to bring specific folders, excluded by default, but needed at that time. Ps: I have lots of software repositories that contains a default folder tree for system documentation, source code and change requests. Checking out the root of this structure simplifies a lot, but brings all change requests. Users are interested in all documentation and in a specific change request folder, not all. I would love this feature! Luiz Guilherme M. Kimel -Mensagem original- De: Autumn [mailto:dsj...@gmail.com] Enviada em: sexta-feira, 10 de setembro de 2010 12:28 Para: Daniel Shahaf Cc: Itamar O; users@subversion.apache.org Assunto: Re: Checkout exclude pattern Cool, that hadn't occured to me. That could mean that no structural changes are required to the .svn format -- only a code change to the checkout logic to preemptively create the exclude entries. I'm not sure how it would handle the case where someone else adds new files which match my pattern, for which no svn_depth_exclude entry yet exists. Ideas? I think under the hood, such a --exclude option would be implemented by setting the depth of the files-matching-the-pattern to svn_depth_exclude. So I'm asking if the desired feature is to be able to set that depth at checkout time, before the files are fetched even once.
Re: Checkout exclude pattern
If the 'checkout' logic can tell the server to not send some files, then so can the 'update' logic. It's just a matter of making it remember to do that. (i.e., having the exclude pattern persist somewhere and used by the 'update' command) Autumn wrote on Fri, Sep 10, 2010 at 08:27:34 -0700: Cool, that hadn't occured to me. That could mean that no structural changes are required to the .svn format -- only a code change to the checkout logic to preemptively create the exclude entries. I'm not sure how it would handle the case where someone else adds new files which match my pattern, for which no svn_depth_exclude entry yet exists. Ideas? I think under the hood, such a --exclude option would be implemented by setting the depth of the files-matching-the-pattern to svn_depth_exclude. So I'm asking if the desired feature is to be able to set that depth at checkout time, before the files are fetched even once.
how to browse older revisions?
Hi, Is it possible to browse (in Firefox or MS IE) older revisions (not HEAD)? Ivan
Re: how to browse older revisions?
On 9/10/2010 1:47 PM, JWalker wrote: Hi, Is it possible to browse (in Firefox or MS IE) older revisions (not HEAD)? The easy approach is to install viewvc for browser viewing and navigation. http://viewvc.org/ -- Les Mikesell lesmikes...@gmail.com
Re: how to browse older revisions?
On Fri, Sep 10, 2010 at 9:57 PM, Andy Levy andy.l...@gmail.com wrote: I think there's a way with the latest version (1.6.x), but I can't find the syntax. https://server/svn/project/trunk/?p=revision number -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: Repository Directory Tree
On Fri, Sep 10, 2010 at 1:42 AM, Lorenz loren...@yahoo.com wrote: Giulio Troccoli wrote: [...] - check out the whole thing (it might be too big but maybe not) svn checkout file:///var/svn ~/tmp This will create a new directory called tmp in your home directory whit the whole of your repository. Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 and var/svn/proj3. - move the projects to the root of your repository cd ~/tmp svn move var/svn/proj1 proj1 svn move var/svn/proj2 proj2 svn move var/svn/proj3 proj3 Since you have used svn command the history will be preserved. - commit svn commit -mReorganising the projects if you don't want to check-out the whole repository, and are working from the command line anyway, you can use svnmucc to do the restructuring in one commit without a working copy. svnmucc mv url1 url2 mv url3 url4 ... -- What, exactly, is wrong with:
Re: Repository Directory Tree
On Fri, Sep 10, 2010 at 5:57 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Fri, Sep 10, 2010 at 1:42 AM, Lorenz loren...@yahoo.com wrote: Giulio Troccoli wrote: [...] - check out the whole thing (it might be too big but maybe not) svn checkout file:///var/svn ~/tmp This will create a new directory called tmp in your home directory whit the whole of your repository. Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 and var/svn/proj3. - move the projects to the root of your repository cd ~/tmp svn move var/svn/proj1 proj1 svn move var/svn/proj2 proj2 svn move var/svn/proj3 proj3 Since you have used svn command the history will be preserved. - commit svn commit -mReorganising the projects if you don't want to check-out the whole repository, and are working from the command line anyway, you can use svnmucc to do the restructuring in one commit without a working copy. svnmucc mv url1 url2 mv url3 url4 ... -- What, exactly, is wrong with: Gahh, web interface messed with my use of tabs in typing: What's wrong with this syntax to do the move without a checkout? svn move [URLOFREPO]/var/svn/proj1 [URLOFREPO/proj1
Re: Hook Script Examples
On Sep 10, 2010, at 10:50, BRM wrote: My old subversion server had a hookscript to deny commits unless there was a log message. I'd like to setup the same functionality on the new subversion server too. I already got my hook-scripts in place, but... In the process, I came across the following README files: http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/README http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/README both of which references the old tigris.org site: http://subversion.tigris.org/tools_contrib.htmlHoweve, the page is no longer available, and I can't find it on the new apache.org site either. Is this page just simply no longer going to be available? Or is there somewhere else for this stuff now? The files are here: http://svn.apache.org/repos/asf/subversion/trunk/contrib/ The tools_contrib.html page was removed earlier this year: http://svn.apache.org/viewvc?view=revisionrevision=900549 Note the hook script to deny commits that have no log message is what you get in the default pre-commit.tmpl file that Subversion creates in every new repository.
