Re: Better way to get the full rule of the last commit?
--- Daniel Becroft On Mon, Oct 11, 2010 at 12:34 PM, Tech Geek wrote: > All my repositories live under /var/lib/svn/. > > Let's the output of the following command (on the SVN server): > # svn changed /var/lib/svn/projectA/ > is > A PartA/tags/DEV-1.00_RC5/ > > Now in my post-commit hook I need the following value in a variable (say > EMAIL_URL): > EMAIL_URL=/var/lib/svn/projectA/PartA/tags/DEV-1.00_RC5 > > Right now the way I am getting this value in my post-commit hook is as > follow: > > DIRCHANGE=`$SVNLOOK changed "$REPOS" | $GREP "^A\W.*" | cut -d' ' -f4` > SRC_CO_PATH="$REPOS/$DIRCHANGE" > > Is there any command which will return the full path of the directory > inside that repository under which the changes were made by the last commit? > Sure, you used it above. 'svnlook changed' will always return the path (relative to the repository root) of the changed file. However, what I think you are after, is the full URL (include repository path) to that file. That is not possible for SVN to determine, as it does not know *how* you are serving the repository (HTTP, HTTPS, svn+ssh, svn, etc). $REPOS will give you the physical path to the repository, not necessarily the publicly accessible path. Cheers, Daniel B.
Re: Proper way to copy files between a branch and trunk
On Fri, Oct 22, 2010 at 5:08 AM, Mark _ wrote: > Hi all, > > I have never understood the proper way to transfer files (or directories) > between a branch and trunk and vice versa. > > Originally I thought the svn copy command was the best command to use, but > then someone on this forum informed me that instead svn merge should be > used, so that in the future updates can easily be transferered using svn > merge again. > > The problem is...svn merge doesn't work :( > > Consider a very simple scenerio: > I add a directory called myFeature to branchX. I then want to copy this > myFeature directory to trunk. Using svn copy everything is fine. But check > what happens when I try to merge: > > $ svn merge http://svn/trunk/myfeat...@head > http://svn/branches/branchX/myfeat...@1234 . > svn: '/product/!svn/bc/389517/trunk/myFeature' path not found. > You've formatted your merge command incorrectly. Merges are done between like levels on a tree. You shouldn't try to merge a subdirectory of a branch with the root of trunk. So, assuming branchX was created via a 'svn copy trunk branchX' command, and the myFeature folder was added in r1234, then you would want to do the following: $ svn merge -c 1234 http://svn/branches/branchX . If there were additional revisions that need to come across, then these would need to be done as well. Trying to think of the output as 'copy directory myFeature from this branch to trunk' seems to be causing headaches. Instead, what you're after is 'take this set of changes from this branch to trunk'. Regards, Daniel B.
Re: Not so incoherent commit
On Thu, Oct 28, 2010 at 7:20 PM, Antonio Ávila wrote: > > Hello all, my name is Antonio Ávila and I'm an svn admin/user. I would like > to share what happens to me yesterday with a not so incoherent tag > operation. > > >1. A team member commits changes in the trunk, at time t. (ending up > in a revision, let's say 2). >2. t+7 minutes later, we tag the trunk with the following command: > > svn cp http://someIp/svn/trunk http://someIp/svn/tags/NewTag > > After some time another team member discover that the changes that should > be in the NewTag aren't there... And the NewTag was generated from trunk, > but revision 1 instead of 2. > > So, what the hell happened? > > Here it comes the answer. > > Everything looked fine with svn info and svn log, the commands were right, > nobody made a mistake, apparently. And the commands looked fine on the > temporal line: first the commit, then the tag operation... > > Looking into the access svn log in the server, what happened was that the > tag operation were "launched but not executed" 10 minutes before the commits > in the trunk and it was waiting for the user to write the comment. So the > temp line was: > > 1.- svn cp http://someIp/svn/trunk http://someIp/svn/tags/NewTag # waiting > in vim... (the rev info has been already taken trunk has rev 1) > 2.- svn ci -m "some comment" # finalizes de operation trunk has now rev 2 > 3.- write comment in vim and :x # finalizes de operation, it doesn't > regather the revs infos, so rev1 is copied into the tag with the comment. > > The "3" step, is registered with "3" time, instead of "1" time (what it's > logical...) > > Well, this is an unusual situation, but it may happen to somebody in the > future and he may not realize what happened, so here is the experience. > Don't leave the svn operation waiting for the comment. > Or craft the log message in an external file and pass that file as the commit message. > Also, I think that the svn client could gather the info after inserting the > comment to avoid this situation. > I don't agree with this. What about the situation where the last commit *is not* supposed to be included in the tag? The revision used for the copy should be the revision at the time the command was initiated (which is exactly what happened in your situation). Otherwise, what you asked the command to operate on, and what it actually operated on, is not the same thing. Cheers, Daniel B.
Re: SVN Usage - working on both tag and trunk
On Thu, Nov 11, 2010 at 4:26 AM, Jonathan dos Santos < jonat...@prioriti.com.br> wrote: > Hello, first of all if I’m infringing any rule on the mailing list I’m > really sorry. I’ve tryied searching but couldn’t find a good phrase to > describe my problem. > > > > I’m pretty new to svn and version control so this question may be very > elementary: > > > > In our company we use SVN to manage the source code of our Delphi > applications, generally we use trunks tomake changes to the source code and > we only generate tags when we need to deploy the implemented features, still > bugs happen and since the software is used in critical processes (at least > for our clients they are critical…) , we need to fix bugs and deploy the > corrections quickly sometimes, > > generally we need to develop both in the trunk and the tag and sometimes > that’s really frustrating – mainly because some processes are huge and after > each minimal change we need to test it over and over in a dozen ways, I try > my best to use patches or to convince the deployer to make a new tag. Still > It happens more often the I wish it too, is there a way to prevent this > through SVN or its more of a company problem unrelated to svn usage? Or > maybe its just me ? > > > > Thanks for your help in advance > It sounds like a little of both. 1) Tags are usually read-only, so you could prevent modification via pre-commit hooks or path-based authorization of some sort. 2) The 'standard' process for using trunk/branches/tags structure is: develop on trunk, merge to a release branch, and system-test there. Once ready, tag the branch. If a change needs to be made (ie urgent fix), then make it on trunk, merge to the release branch, and re-tag. Cheers, Daniel B.
Re: Sparse checkouts automation
On Thu, Nov 11, 2010 at 9:10 AM, San Martino wrote: > Hello, > > Suppose you have a layout like this: > /trunk >/dir1 > /dir1_1 > file1.txt > file2.txt > /dir1_2 > > Is there a way with one command to sparse-checkout al the elements > of the path to file1.txt (included) but no more than those elements ? > > That is, the local working copy should look like this after one command: > /trunk > /dir1 > /dir1_1 > file1.txt > > Note that file2.txt and dir1_2 won't appear. > With one command, no. But you can do the following: svn checkout --depth=empty svn://host/repository/trunk trunk cd trunk svn update --depth=empty dir1 cd dir1 svn update --depth=empty dir1_1 cd dir1_1 svn update file1.txt There's probably a quicker method of doing it, but you'll still need multiple commands. Cheers, Daniel B.
Merging case-only renames to branch
Hi, We've recently had to rename a couple of files on trunk by case only (e.g. FOO.C to foo.c), which we did via a URL-only rename. This worked perfectly. We then encountered a strange error when attempting to merge this revision across to our release branch. Because the revision contains both an ADD and a DELETE for (essentially) the same file, we got an "Error bumping revisions post-commit)" message. I've reproduced the error with a sandpit environment using 1.6.13 (below). --- Merging r4 through r5 into '.': AA\alpha.txt DA\ALPHA.TXT Sending. Deleting A\ALPHA.TXT Adding A\alpha.txt svn: Commit succeeded, but other errors follow: svn: Error bumping revisions post-commit (details follow): svn: In directory 'D:\temp\svn_sandpit\workingcopy\branchA\A' svn: Error processing command 'committed' in 'D:\temp\svn_sandpit\workingcopy\branchA\A' svn: Error getting 'affected time' for 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base' svn: Can't stat 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base': The system cannot find the file specified. Interestingly, if I change my reproduction script to rename from alpha.txt to ALPHA.txt, the commit works correctly. --- Merging r4 through r5 into '.': AA\ALPHA.TXT DA\alpha.txt Sending. Adding A\ALPHA.TXT Deleting A\alpha.txt Committed revision 6. My question(s) are: 1) How should a merge of a case-only rename be managed? Is it a matter of merging up to rX, manually renaming in the branch, recording the merge for rX, then merging the rest? Or is there a cleaner method? 2) Should the order of the rename actually matter? In the above example(s) renaming of UPPER to lower caused the error, but renaming from lower to UPPER did not. The same script (running using an old build of 1.7) gives the following message: --- Merging r4 through r5 into '.': AA\alpha.txt DA\ALPHA.TXT --- Recording mergeinfo for merge of r4 through r5 into '.': U . Sending. Deleting A\ALPHA.TXT Adding A\alpha.txt svn: Commit succeeded, but other errors follow: svn: Error bumping revisions post-commit (details follow): svn: Error processing post-commit work for 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt' svn: File 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt' has no text base Different wording, but same problem. --- Daniel Becroft
Re: Merging case-only renames to branch
On Mon, Nov 15, 2010 at 11:44 PM, David Weintraub wrote: > On Sun, Nov 14, 2010 at 7:12 PM, Daniel Becroft > wrote: > > Hi, > > > > We've recently had to rename a couple of files on trunk by case only > (e.g. > > FOO.C to foo.c), which we did via a URL-only rename. This worked > perfectly. > > > > We then encountered a strange error when attempting to merge this > revision > > across to our release branch. Because the revision contains both an ADD > and > > a DELETE for (essentially) the same file, we got an "Error bumping > revisions > > post-commit)" message. I've reproduced the error with a sandpit > environment > > using 1.6.13 (below). > > Okay, you're using Windows. On Windows, Foo and foo are the same file, > but on Unix, they're two different files. Subversion is suppose to be > case sensitive, so Foo and foo are two different files in Subversion > whether or not the server or client are on Windows systems or Unix > systems. > I realize that, hence why we did our initial renames via URLs, rather than in a working copy. My question was not so much "Why did I get this message?", but how should such a change be merged between trunk and branch. Any merge requires a working copy. I suspect that the correct method is: - Merge everything up to and including) rX-1, and commit. - Rename file manually over URL - Record-only merge of rX - Merge everything from (and including) rX+1 to HEAD, and commit. > Do you have any post-commit hooks? If you are, are the messages being > generated by Subversion or the post commit hooks? > The messages are being generated by the client (there were no post-commit hooks in my sample repository). Cheers, Daniel B.
URL-only renames adds svn:mergeinfo property
Hi, I've just found (another) issue with using URL-only renames. If one of the parent directories has svn:mergeinfo recorded on it, then renaming a file via a URL results in the new file containing a full copy of what was on the trunk (but cut down to the individual file). Please see the following output from my test script (using SVN 1.6.13): >svn merge file:///D:/temp/svn_sandpit/repository/trunk . --- Merging r4 through r5 into '.': UA\alpha.txt >svn commit . --message "Merge r5 from trunk to branch." Sending. SendingA\alpha.txt Transmitting file data . Committed revision 6. >svn propget svn:mergeinfo file:///D:/temp/svn_sandpit/repository/branches/branchA /trunk:4-5 >svn propget svn:mergeinfo file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt >svn rename file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message "Rename alpha.txt to beta.txt on branchA." Committed revision 7. >svn propget svn:mergeinfo file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt /trunk/A/alpha.txt:4-5 Notice that the 'svn propget' on alpha.txt indicates that there is no svn:mergeinfo property available, but it gets added to beta.txt during the rename. Is this intended behavior? Daniel Becroft
Re: URL-only renames adds svn:mergeinfo property
On Tue, Nov 16, 2010 at 3:54 PM, Daniel Becroft wrote: > Hi, > > I've just found (another) issue with using URL-only renames. If one of the > parent directories has svn:mergeinfo recorded on it, then renaming a file > via a URL results in the new file containing a full copy of what was on the > trunk (but cut down to the individual file). > > Please see the following output from my test script (using SVN 1.6.13): > > >svn merge file:///D:/temp/svn_sandpit/repository/trunk . > --- Merging r4 through r5 into '.': > UA\alpha.txt > > >svn commit . --message "Merge r5 from trunk to branch." > Sending. > SendingA\alpha.txt > Transmitting file data . > Committed revision 6. > > >svn propget svn:mergeinfo > file:///D:/temp/svn_sandpit/repository/branches/branchA > /trunk:4-5 > > >svn propget svn:mergeinfo > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt > > >svn rename > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message > "Rename alpha.txt to beta.txt on branchA." > Committed revision 7. > > >svn propget svn:mergeinfo > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt > /trunk/A/alpha.txt:4-5 > > Notice that the 'svn propget' on alpha.txt indicates that there is no > svn:mergeinfo property available, but it gets added to beta.txt during the > rename. > > Is this intended behavior? > Is anyone able to confirm if this is intended behavior? After further testing, I get the same results if I run an 'svn copy' via URLs. However, I do not get the svn:mergeinfo property added if I 'svn rename' or 'svn copy' in my working copy. Cheers, Daniel B.
Re: URL-only renames adds svn:mergeinfo property
On Wed, Nov 24, 2010 at 6:31 AM, Paul Burba wrote: > On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling wrote: > > Hi All, > > The short story, the following behaviors are intentional: > > A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo > if the source has it. > > B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit > mergeinfo if the source has it. If the source doesn't have explicit > mergeinfo, but inherits it, then that inherited mergeinfo is made > explicit on the destination. > > The slightly longer story... > > As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'. > When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't > change the URL-to-* behavior. But honestly, this was probably as much > out of caution as for any other reason, since there are use cases > where 'B' helps you even when doing copies within the same branch (see > my example that follows). > > If someone wants to make the argument on the dev list that 'A' should > be the default behavior for all copies and moves, I for one am quite > willing to listen and probably assist, and maybe do all the coding > (which should be pretty minimal), but this isn't on my personal TODO > list at the moment. > I'm not sure I have a firm argument either way (yet). It is a little strange that the same command would produce different results when done WC-to-WC vs URL-to-*. > > On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote: > >> I don't see why it matters that it's a "sub-branch". It's still a > >> (grand-)child of mybranch, so can perfectly inherit that mergeinfo. > >> AFAIU it only needs explicit mergeinfo if it starts to deviate from > >> the mybranch root (e.g. if something is (sync-)merged directly to the > >> sub-branch). Or am I missing something? > > > > Hmmm.. I don't see any reason either. Explicit mergeinfo could probably > be > > created later when the subtree actually becomes a merge target. > > I guess the current logic in the code simply doesn't account for the case > > where the copy destination is a child of the source? Not sure. > Now let's try the same merge, but targeting psi-WC. We know from the > preceding diagram that psi-WC's merge history should be semantically > equivalent to psi-URL's and we *should* get a no-op, but instead... > > >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6 > Conflict discovered in 'branch/D/H/psi-WC'. > Select: (p) postpone, (df) diff-full, (e) edit, > (mc) mine-conflict, (tc) theirs-conflict, > (s) show all options: p > --- Merging r6 into 'branch\D\H\psi-WC': > Cbranch\D\H\psi-WC > Summary of conflicts: >Text conflicts: 1 > But merging the parent directories is a no-op, because the explicit merge info on /branch stops r6 from being merged again. > Why did this happen? Because psi-WC's actual merge history (i.e. its > natural history and explicit/implicit mergeinfo) doesn't include > '/trunk/D/H/psi:6'. > > Now you may be thinking, "but doesn't it inherit that history from the > root of branch?". Unfortunately it doesn't, it does inherit mergeinfo > from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously > not what we are merging and has the added distinction of not even > existing in the repository** > > This is because mergeinfo inheritance is a simple path-wise > calculation: A path without mergeinfo inherits the mergeinfo of its > nearest parent with explicit mergeinfo, with all the merge source > paths adjusted by the path difference between the path and its parent. > > Yes, I'd love to come up with a more concise way to explain that! > The mergeinfo (from the parent) is /trunk:6, which means that the changes made to /trunk in r6 have already been merged into a parent. I guess it's naive for SVN to work out that I'm trying to merge a change to a sub-tree of /trunk to a sub-tree of /branches, when the same revision has been merged into a parent. I guess it's because SVN only looks at the merge target itself when determine the eligible revisions, rather than walking the tree until it hits a node with explicit mergeinfo. > Anyhow, that is where not recording the source's inherited mergeinfo > on the copy destination can bite us. Is is a big problem? Not sure, > but the workaround to avoid it, using WC-to-WC copies, doesn't seem > that draconian. If you agree or not, I'm more than happy to kick > around improvements on the dev list. > Agreed. The case that I had came about due to a case-only rename, and because we run windows, we did it via a URL (rather than an intermediate commit). We'll know for next time. :-) > Thanks, > > Paul > > * I talk about copies here, but the same issues apply to moves. > > ** In 1.7 I made improvements so that such bogus inherited mergeinfo > doesn't get recorded, see > http://subversion.tigris.org/issues/show_bug.cgi?id=3669, but in > 1.5-1.6 we have that added insult. >
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 7:59 AM, Andrey Repin wrote: > Greetings, Les Mikesell! > > >> thanks for having responded. > >> Can I file a feature request for that in the issue tracker, > >> what do you think? > >> > >> @Ryan: Of course with a peg rev I can log that single rev. But the > >> rev number of that rev is that what we are looking for! To find out > >> this rev number, we want to use an earlier peg rev where we know > >> that the file still existed and want to add "-r1:head" as operative > >> revs to see all revs including the rev where the file was deleted. > >> > > > The deletion should show in an 'svn log -v' of the directory where the > file was > > deleted. > > That directory was deleted as well. As well, at unknown revision. Multiple > times. > > The question is not that we can work around the issue, the question is, why > Subversion can't do this for us? I can add my own case to this list. > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1850347 > > I can understand that it's not easy to track deletes/copies forward, but > tracking history from creation time to deletion(renamind implies > deletion) time should be possible IMO. > And this should be possible without user's guesswork. It's fairly simple to > find correct revision range in repository with 40 commits. > In repository with 40,000 commits things became "a bit" scary Have you tried a combination of 'log -v' and grep? IMHO, that would be the quickest to implement, and simplest to achieve. Cheers, Daniel B.
Re: external file
On 02/12/2010, at 20:30, Scott Yan wrote: > Hi, > > At first, thanks for your great works, but our company really need > inter-repository file-externals feature which is not supported now, so , is > there any plan to do this? > > Below is our situation: > There are a dozen sub-factories in our company , and we develop our ERP > system ourselves, because there are very much diffrences between factories, > our project became a dozen versions, which means we have a dozen repositoies > for all the projects. This scenario sound like you should probably have one repository with separate branches per version, rather than individual repositories. Then you wouldn't need externals at all. > Obviously, there are many files are equal in these projects, we must share > them between projects, but it's very difficult to share the whole directory > because of many reason such as: > 1. We use VSS before, and VSS support file share between projects, so we > didn't place share files in seperate folder. > 2. Usually, when we add a new module to the system , the whole module is > shared in all the projects, but factories will ask some special functions for > their own request, and there will be more and more files are diffrent from > other projects. > 3. there are several files are placed at root directory. > > For clearer description, I'll demonstrate our situation: > Suppose there are 3 projects > Project1 > Project2 > Project3 > > There is a "HRManagement" folder in all of them. > There are 100 files in HRManagement folder, 30 of them are equal between > Project1, Project2 and Project3, but the others are not equal. > > If we make a new folder names "Share" below HRManagement, and place the 30 > files to it: > HRManagement/Share/sharefile1 > HRManagement/Share/sharefile2 > HRManagement/Share/sharefile3 > .. > > Because we reference sharefile1 as "HRManagement/sharefile1" before, so we > must search the whole project ( in face, in all the projects, Project1, > Project2, and Project3) for the old reference , and then change to > "HRManagement/Share/sharefile1". > And, this is just for a single file! There are sharefile2, > sharefile3,.. to do the same work, which is impossile at all. And if one of these shared files needed to be changed for a single version, you would have to undo all that work. Again, branches sound like a better fit. > Thanks for reading this , and I really hope you will add the feature ... > > > Best Regards > Scott.Yan > >
Re: external file
On Sat, Dec 4, 2010 at 10:35 AM, Scott Yan wrote: > Hi, djcbecroft: > > Thanks very much for your reply , but I'm afraid that branches can't meet > my request. Because when we make some change to any projects, we want the > changes reflect to all other projects just as external does, but when I > modify a file in a branch, other branches won't know that until I do a > merge, so , that means if I modify a file in project1, I must goto project2 > to do a merge, and then project3, and then more, besides, we modify the > files really frequently. > Please remember to Reply All to ensure the conversation stays on the list. Maybe. You can use branches, and then use intra-repository file externals to avoid merging the changes across. Cheers, Daniel B. > Best Regards > Scott.Yan > > > > > CC: users@subversion.apache.org > > From: djcbecr...@gmail.com > > Subject: Re: external file > > Date: Thu, 2 Dec 2010 23:09:57 +1000 > > To: scott...@live.com > > > > > On 02/12/2010, at 20:30, Scott Yan wrote: > > > > > Hi, > > > > > > At first, thanks for your great works, but our company really need > inter-repository file-externals feature which is not supported now, so , is > there any plan to do this? > > > > > > Below is our situation: > > > There are a dozen sub-factories in our company , and we develop our ERP > system ourselves, because there are very much diffrences between factories, > our project became a dozen versions, which means we have a dozen repositoies > for all the projects. > > > > This scenario sound like you should probably have one repository with > separate branches per version, rather than individual repositories. Then you > wouldn't need externals at all. > > > > > Obviously, there are many files are equal in these projects, we must > share them between projects, but it's very difficult to share the whole > directory because of many reason such as: > > > 1. We use VSS before, and VSS support file share between projects, so > we didn't place share files in seperate folder. > > > 2. Usually, when we add a new module to the system , the whole module > is shared in all the projects, but factories will ask some special functions > for their own request, and there will be more and more files are diffrent > from other projects. > > > 3. there are several files are placed at root directory. > > > > > > For clearer description, I'll demonstrate our situation: > > > Suppose there are 3 projects > > > Project1 > > > Project2 > > > Project3 > > > > > > There is a "HRManagement" folder in all of them. > > > There are 100 files in HRManagement folder, 30 of them are equal > between Project1, Project2 and Project3, but the others are not equal. > > > > > > If we make a new folder names "Share" below HRManagement, and place the > 30 files to it: > > > HRManagement/Share/sharefile1 > > > HRManagement/Share/sharefile2 > > > HRManagement/Share/sharefile3 > > > .. > > > > > > Because we reference sharefile1 as "HRManagement/sharefile1" before, so > we must search the whole project ( in face, in all the projects, Project1, > Project2, and Project3) for the old reference , and then change to > "HRManagement/Share/sharefile1". > > > And, this is just for a single file! There are sharefile2, > sharefile3,.. to do the same work, which is impossile at all. > > > > And if one of these shared files needed to be changed for a single > version, you would have to undo all that work. Again, branches sound like a > better fit. > > > > > Thanks for reading this , and I really hope you will add the feature > ... > > > > > > > > > Best Regards > > > Scott.Yan > > > > > > >
Re: svn log -g --xml doesn't include "Merged via" info
On Mon, Dec 6, 2010 at 6:52 AM, Stanimir Stamenkov wrote: > Issuing 'svn log -g -q' I get an output like: > > > r8 | ... > > r7 | ... > Merged via: r8 > > r6 | ... > Merged via: r8 > > r5 | ... > Merged via: r8 > > r4 | ... > Merged via: r8 > > r3 | ... > > r2 | ... > > r1 | ... > > > However issuing 'svn log -g --xml -q' (even 'svn log -g --xml -v') > doesn't seem to provide the "Merged via" revision info. Is it > currently possible to get the additional information from merge > history using the XML output format? > The merged revisions are shown as nested elements. For example: 2010-11-19T06:17:01.744981Z Merged r10426 from trunk. 2010-11-19T06:08:13.934595Z Cheers, Daniel B.
Re: svnadmin create and not being method agnostic
On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling wrote: > On Mon, Jan 03, 2011 at 02:35:08PM +0100, Stefan Sperling wrote: > > On Sat, Jan 01, 2011 at 11:58:09PM -0700, Philip Prindeville wrote: > > > I don't care how you do that. As long as it's easily > > > understandable, preferably to both existing users and new ones. > > > > Apart from improving documentation, I cannot think of a way to do this > > which is easily understandable for everyone, sorry. > > Philip (and others), > > Having slept over it, I could come up with a way to do this that is > (as far as I can tell) consistent, backwards compatible, and doesn't > leave behaviour unspecified. The basic trick is to do a repository > format bump. > > However, this goes far beyond adding a new option to svnadmin create > as you originally envisioned, so you may not like this approach. > > I'm not sure if the community would like this. I won't object to > something like this, though I still don't see a lot of added value > coming from it. I won't pursue this further on my own. If you want > this to happen please review the specification below and try to > find holes or errors in it. We could then discuss this further on > the dev@ list to gather feedback, commit it to the Subversion > tree under /trunk/notes/, and file an ENHANCEMENT issue in the issue > tracker. > Maybe someone will like the idea and will eventually come up with a patch. > > If you have more ideas for improving Subversion, we're always glad > to hear them. However to really get anywhere, new ideas must carefully > be thought through and specified well. Discussion such as this one, even > if it may seem rigorous and harsh, is an integral part of making that > happen. > So I hope you don't feel put off by it. > > Stefan > > > > = Proposal: New servers.conf configuration file in Subversion Repository = > > Subversion repositories can be served over the network by several > server implementations (SI), currently mod_dav_svn and svnserve. > > The goal of this proposal is to provide admins with an easy way to control > which SI will serve a given repository, by editing a configuration file > inside the repository. > > Use cases are: > > A) preventing a repository from being accidentally served by an SI > that has incorrectly been configured to serve the repository > (repositories need to explicitly opt-in to being served by a particular > SI) > > B) moving repositories from one SI to another in the case where multiple > repositories are each served by one and only one of several SIs, > without changing the server configuration or repository location > > To realize use case A, admins currently have to: > - understand configuration mechanisms of all SIs in order to >enable or disable repositories per SI > - make sure that repositories that shall be served by a particular >SI are only readable and writable by processes of that SI, and not >by any other processes (each such process could be a misconfigured >Subversion SI) > With this proposal admins will only have to understand how to configure > on SI, as they have to explicitly enable serving by an SI for each > repository. > This provides a layer of protection against accidental server > misconfiguration. > > To realize use case B, admins currently have to: > - understand configuration mechanisms of all SIs in order to >enable or disable repositories per SI > - either move repositories around in the server filesystem >or change the SI configuration > With this proposal admins still need to understand how to configure > all SIs, but the instead of moving a repository or changing server > configuration files, it is sufficient to edit a single configuration > file within the repository. > > = Impact on the repository format = > > A format bump (in REPOS/format, not REPOS/db/format) is required. > The new feature shall only be activated for repositories with the new > format number in REPOS/format. > > A new file will be created at REPOS/conf/servers.conf inside the > repository. > It contains configuration directives in an ini-style format so that > existing > configuration file parsers in the Subversion code base can be used. > What's the impact of using svnserve with a --config-file argument? > The default content of this file is as follows: > > # This file specifies which Subversion server implementations > # may serve this repository. > # > # Uncomment the following lines to enable serving by mod_dav_svn > #[mod_dav_svn] > #enabled = yes > # > # Uncomment the following lines to enable serving by svnserve > #[svnserve] > #enabled = yes > So, by default, serving for the repository is disabled. > Shouldn't the current behaviour of 'svnadmin create' be maintained? At the moment, a user can just do: svnadmin create .\repository svnserve -r . and a repository is created and served via svnserve. With the above defaults, a third step is required, which can get tedious. I'd propose enabling
Re: svnadmin create and not being method agnostic
On Wed, Jan 5, 2011 at 12:31 PM, Nico Kadel-Garcia wrote: > On Tue, Jan 4, 2011 at 4:56 PM, Daniel Becroft > wrote: > > > svnadmin create .\repository > > svnserve -r . > > > > and a repository is created and served via svnserve. With the above > > defaults, a third step is required, which can get tedious. I'd propose > > enabling svnserve by default, and it can then be disabled if required. > This > > also maintains the ease of creating test scripts to try and reproduce > > issues. > > It's *too* easy. And that's a problem why? > Since the default svnserve.conf is very permissive, > and because default svnserve is on an unprivileged port so any user > can serve anyone else's "readable" repository to outside access, > The port that it runs on by default is irrelevant. svnserve can be started to run on 'any' open port, so why does the default port matter? If someone wanted to, they could run svnserve on port 80. > without the original author's knowledge or explicit consent. The > default permissions of "svnadmin create" and "svnadmin hotcopy" are > much too permissive, and the concatenation of separate "the admin > should set these if they want" options creates a quite noticeable > security risk. > I think the notion of "too permissive" is the problem. My definition is going to be different from yours, which is going to be different to the man on the corner. I don't have an issue with adding something to lock down a given repository from not being served by svnserve, but I'm questing why it should be restricted _by default_. As a user, if I wanted to try using SVN for the first time, the simpler it is to setup a repository and use it, the better. And, as I mentioned before, this is also applicable when creating and destroying sandpit repositories to reproduce bugs or test ideas. All I'm asking for, is that 'svnadmin create' (both with and without this proposed change) should create a repository that can be served using the provided svnserve, without modifying any configuration files. Add a new configuration file, or new command-line options to switch it off, but leave the default alone. > Stefan's more sophisticated "let's set up a configuration file that > restricts forms of access" is interesting, but would be at least 2 > years away from release given the burden of other critical issues in > subversion-1.7 planned changes, and would be awkward to backport to > "enterprise" systems such as the extremely out of date > subversion-1.4.x on RHEL 5. >
Re: SVN Hooks to require log message, limit size and file type
On Wed, Jan 12, 2011 at 11:46 AM, David Xie wrote:
> Hello,
>
> I am looking for a hook to require log message when commit. I succeded to
> do it.
>
> At the same time, I want to limit size less than 10MB and forbid .zip .7z
> .rar file type.
> I found some hooks from internet, tried multi times but all failed. I could
> always commit big than 10M files and zip files. I struggled two days but
> could not resolve it.
>
> I post my pre-commit at the end.
> RHEL 5.3
> SVN 1.6.15
> Apache 2.2.14
> Java 1.6.0_17
>
> Would someone give me some help? Great thanks!
>
> Regards,
> David
>
I'm unfamiliar with unix scripting, but you could try outputting debug
messages to a basic text file, so you can trace it through as it runs.
Cheers,
Daniel B.
> pre-commit :
> #!/bin/sh
> REPOS="$1"
> TXN="$2"
> MAX_SIZE=1024
> MIN_LOG=10
> FILTER='\.(zip|rar|o|obj|tar|gz)$'
> SVNLOOK=/local/svnroot/subversion/bin/svnlook
> # Make sure that the log message contains some text.
> LOGMSG=$($SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c)
> if [ "$LOGMSG" -lt $MIN_LOG ]
> then
> echo -e "Please enter at least 10 characters for log message. Questions,
> contact David" >&2
> exit 1
> fi
>
> files=$($SVNLOOK changed -t $TXN $REPOS |awk '{print $2}')
> for f in $files
> do
>
> #check file type
> if echo $f|tr A-Z a-z|grep -Eq $FILTER
> then
> echo "File $f is not allow ($FILTER) file" >&2
> exit 1
> fi
>
> #check file size
> filesize=$($SVNLOOK cat -t $TXN $REPOS $f|wc -c)
> if [ "$filesize" -gt "$MAX_SIZE"]
> then
> echo "File $f is too large(must <=$MAX_SIZE)" >&2
> exit 1
> fi
>
> done
>
> #All checks passed, so allow the commit.
> exit 0
>
>
Re: SVN Subversion- object level checkout
On Thu, Jan 13, 2011 at 5:24 PM, wrote:
> Hello Micheal,
>
> Thanks for your mail.
>
> We are using Tortoise SVN-1.6.7 alongwith Power Builder 11.5.
>
> We want to lock (check-out) the core power builder object from SVN so
> that only one user can modify the object for that time. For this case,
> If we want to open the workspace from the repository (SVN) we are
> getting the attached message.
>
> Please let us know the correct process for the Power Builder connectivty
> with the proper Tortoise SVN SCC version to lock the core PB object.
>
> Appreciate your quick help.
>
> Regards,
>
I'm guessing that .PBW file relies on the rest of the files in that
directory. You'll need to checkout that directory prior to opening.
Cheers,
Daniel B.
> Amit Sasmal.
> Wipro Technologies.
>
>
> -Original Message-
> From: Michael Diers [mailto:mdi...@elego.de]
> Sent: Wednesday, January 12, 2011 7:27 PM
> To: SOURAV ROY (WT01 - Manufacturing)
> Cc: users@subversion.apache.org; Sudip Datta (WT01 - Manufacturing);
> Pabitra Mallick (WT01 - Manufacturing); Avik Nandi (WT01 -
> Manufacturing); Amit Sasmal (WT01 - Manufacturing)
> Subject: Re: SVN Subversion- object level checkout
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2011-01-12 09:57, sourav.s...@wipro.com wrote:
> [...]
> > We will use Tortoise SVN (Subversion) as version control system or SCM
>
> > tool for our project. We are facing an issue for which we would like
> > to get a solution.
> >
> > We are linking SVN to Powerbuilder 11.5. We are trying to checkout
> > files at object level. Every .pbl file, have many files inside. But
> > SVN is not able to checkout those individual files which are inside
> the pbl file.
> > So is there a way by which SVN can checkout those files which are
> > inside pbl.
> >
> > TortoiseSVN 1.6.7, 2010/01/22
> > Subversion 1.6.9
> [...]
>
> Sourav,
>
> you need to play by PowerBuilder's rules, I'm afraid. Trying to use
> TortoiseSVN or any other "plain" Subversion client for checkin/checkout
> will cause you grief.
>
> You can still use TortoiseSVN for other tasks, like browsing logs,
> tagging and branching.
>
> The IDE supports the SCC API, and you need to use a plug-in for the IDE
> that can drive Subversion via SCC. This will magically do the right
> thing with objects in PBLs. Note that SCC encourages a serialized
> workflow with reservation ("locking") of objects.
>
> We evaluated PushOK's product a couple of years ago; at the time, it
> proved a good fit for our customer's needs.
>
> http://stackoverflow.com/questions/1162141/is-there-a-viable-scc-integra
> tion-for-subversion
>
> (Please upgrade to Subversion 1.6.15. Subversion 1.6.9 sports a number
> of bugs that have been fixed since its release.)
>
> - --
> Michael Diers, elego Software Solutions GmbH, http://www.elego.de
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0ts0EACgkQcEKlWnqVgz0QngCfcTZ5gHe8upwsAH5x3zNZbFXB
> 6vEAn27V2eskpxWfOfh5Hyu6747LFZlg
> =jf++
> -END PGP SIGNATURE-
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>
Compiling subversion on Ubuntu 10.10
Hi, I've had some issues compiling Subversion and APR in my Ubuntu environment (the below output is done from /trunk - I haven't tried a 1.6.x branch yet). Running ./autogen.sh and ./configure work correctly, however I get the following error when running 'make': -- making all in apr make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr' make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr' sed 's,^\(location=\).*$,\1installed,' < apr-1-config > apr-config.out sed 's,^\(apr_build.*=\).*$,\1/usr/local/apr/build-1,' < build/apr_rules.mk> build/apr_rules.out make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr' make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr' -- completed all in apr -- making all in apr-util make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr-util' Making all in xml/expat make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr-util/xml/expat' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util/xml/expat' make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr-util' /bin/bash /libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/home/djcbecroft/dev/subversion/apr-util/include -I/home/djcbecroft/dev/subversion/apr-util/include/private -I/home/djcbecroft/dev/subversion/apr/include -I/home/djcbecroft/dev/subversion/apr-util/xml/expat/lib -o buckets/apr_brigade.lo -c buckets/apr_brigade.c && touch buckets/apr_brigade.lo /bin/bash: /libtool: No such file or directory make[2]: *** [buckets/apr_brigade.lo] Error 127 make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util' make: *** [external-all] Error 1 After investigation, it seems that the path for LIBTOOL was defined incorrectly. I had to change apr-util/build/rules.mk:38 from: LIBTOOL=$(SHELL) $(top_builddir)/libtool to LIBTOOL=$(SHELL) $(apr_builddir)/libtool I'm unfamiliar with how the configure scripts work, so I'm not sure if this is a problem with the SVN scripts, APR scripts, or my system itself. If it's one of the first two, then I'll report it to the appropriate list. Can anyone provide any guidance? --- Daniel Becroft
Re: Compiling subversion on Ubuntu 10.10
Apologies, I also had to make the same change to apr/build/apr_rules.mk:38. --- Daniel Becroft On Sat, Jan 15, 2011 at 8:45 AM, Daniel Becroft wrote: > Hi, > > I've had some issues compiling Subversion and APR in my Ubuntu environment > (the below output is done from /trunk - I haven't tried a 1.6.x branch yet). > > Running ./autogen.sh and ./configure work correctly, however I get the > following error when running 'make': > > -- making all in apr > make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr' > make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr' > sed 's,^\(location=\).*$,\1installed,' < apr-1-config > apr-config.out > sed 's,^\(apr_build.*=\).*$,\1/usr/local/apr/build-1,' < build/ > apr_rules.mk > build/apr_rules.out > make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr' > make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr' > -- completed all in apr > -- making all in apr-util > make[1]: Entering directory `/home/djcbecroft/dev/subversion/apr-util' > Making all in xml/expat > make[2]: Entering directory > `/home/djcbecroft/dev/subversion/apr-util/xml/expat' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory > `/home/djcbecroft/dev/subversion/apr-util/xml/expat' > make[2]: Entering directory `/home/djcbecroft/dev/subversion/apr-util' > /bin/bash /libtool --silent --mode=compile gcc -g -O2 -pthread > -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE > -I/home/djcbecroft/dev/subversion/apr-util/include > -I/home/djcbecroft/dev/subversion/apr-util/include/private > -I/home/djcbecroft/dev/subversion/apr/include > -I/home/djcbecroft/dev/subversion/apr-util/xml/expat/lib -o > buckets/apr_brigade.lo -c buckets/apr_brigade.c && touch > buckets/apr_brigade.lo > /bin/bash: /libtool: No such file or directory > make[2]: *** [buckets/apr_brigade.lo] Error 127 > make[2]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/djcbecroft/dev/subversion/apr-util' > make: *** [external-all] Error 1 > > After investigation, it seems that the path for LIBTOOL was defined > incorrectly. I had to change apr-util/build/rules.mk:38 from: > > LIBTOOL=$(SHELL) $(top_builddir)/libtool > to > LIBTOOL=$(SHELL) $(apr_builddir)/libtool > > I'm unfamiliar with how the configure scripts work, so I'm not sure if this > is a problem with the SVN scripts, APR scripts, or my system itself. If it's > one of the first two, then I'll report it to the appropriate list. Can > anyone provide any guidance? > --- > Daniel Becroft >
Re: Compiling subversion on Ubuntu 10.10
On Mon, Jan 17, 2011 at 7:22 AM, Daniel Shahaf wrote: > Daniel Becroft wrote on Sat, Jan 15, 2011 at 08:45:31 +1000: > > After investigation, it seems that the path for LIBTOOL was defined > > incorrectly. I had to change apr-util/build/rules.mk:38 from: > > > > LIBTOOL=$(SHELL) $(top_builddir)/libtool > > to > > LIBTOOL=$(SHELL) $(apr_builddir)/libtool > > > > What version is that? My 1.4.2 already says the latter. > I was using the 1.3.x branch of both apr and apr-util, because that's what the error message from the ./configure script told me to get (line 4350). I've switched both apr and apr-util to the 1.4.x branch, re-ran ./autogen.sh and ./configure.sh, but still get the same results (extract of apr/build/ apr_rules.mk below). Looks like it might be something on my machine. Cheers, Daniel B. # Some layouts require knowing what version we are at. APR_MAJOR_VERSION=1 APR_DOTTED_VERSION=1.4.3 CC=gcc RM=rm AWK=mawk SHELL=/bin/bash LIBTOOL=$(SHELL) $(top_builddir)/libtool > > I'm unfamiliar with how the configure scripts work, so I'm not sure if > this > > is a problem with the SVN scripts, APR scripts, or my system itself. If > it's > > one of the first two, then I'll report it to the appropriate list. Can > > anyone provide any guidance? > > --- > > Daniel Becroft >
Re: Trival merge of big text file: Dismal performance, 540x faster if binary.
On Fri, Jan 21, 2011 at 7:19 PM, Johan Corveleyn wrote:
> On Mon, Jan 17, 2011 at 5:30 PM, krueger, Andreas (Andreas Krüger,
> DV-RATIO) wrote:
> > Hello, Daniel and all,
> >
> >> In other words, merging changes from file.c@BRANCH to trunk should
> >> detect that file@trunk and file@BRANCH@BRANCH-CREATION are the same
> >> node-revision?
> >
> > I think that my intended optimization should work in this case.
> > But I don't think that's the condition I mean.
> >
> > It does not feel general enough.
> >
> > But then, I also don't think this has to be discussed in the context
> > of this optimization proposal. After all, there is some condition
> > already implemented. SVN already knows how to check
> > whether a merge is possible or not in the binary case.
> >
> > That condition IS what I want.
> >
> > If a binary merge would be possible, be fast and do the binary merge
> > and don't bother with text diffs.
> >
> >
> >> but giving the question more
> >> visibility (as opposed to burying it in the middle of a paragraph on
> >> users@) might help you get an answer. :-)
> >
> > Thanks for the hint!
> >
> > I'd be more than willing to convert this to an issue at
> > http://subversion.tigris.org/issues .
> >
> > Writing a self-contained script that demonstrates the performance
> > problem (starting with the creation of a scratch SVN repository) -
> > would that be a good next step?
>
> Hi Andreas,
>
> Yes, I think you should probably file an issue for this in the issue
> tracker, referring to this thread. If you could write a self-contained
> script to demonstrate, that would certainly be a good thing.
>
> Just to confirm your hypothesis about the special shortcut in "svn
> merge" for binary files, here is the relevant excerpt from
> subversion/libsvn_client/merge.c (starting at line 1454):
>
> [[[
> /* Special case: if a binary file's working file is
> exactly identical to the 'left' side of the merge, then don't
> allow svn_wc_merge to produce a conflict. Instead, just
> overwrite the working file with the 'right' side of the
> merge. Why'd we check for local mods above? Because we want
> to do a different notification depending on whether or not
> the file was locally modified.
>
> Alternately, if the 'left' side of the merge doesn't exist in
> the repository, and the 'right' side of the merge is
> identical to the WC, pretend we did the merge (a no-op). */
> if ((mimetype1 && svn_mime_type_is_binary(mimetype1))
> || (mimetype2 && svn_mime_type_is_binary(mimetype2)))
>{
> /* For adds, the 'left' side of the merge doesn't exist. */
> svn_boolean_t older_revision_exists =
> !merge_b->add_necessitated_merge;
> svn_boolean_t same_contents;
> SVN_ERR(svn_io_files_contents_same_p(&same_contents,
> (older_revision_exists ?
>older_abspath :
> yours_abspath),
> mine_abspath, subpool));
> if (same_contents)
>{
> if (older_revision_exists && !merge_b->dry_run)
>{
> SVN_ERR(svn_io_file_move(yours_abspath, mine_abspath,
> subpool));
>}
> merge_outcome = svn_wc_merge_merged;
> merge_required = FALSE;
>}
>}
> ]]]
>
> See also:
>
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?view=markup
>
> That said, I'm not so sure that we could blindly take this same
> shortcut for text files. It sounds like a trivial decision, but there
> might be some hidden problems if we do this. We just need to be
> careful, and think this through ...
>
(deja vu, I've just been looking at this bit of code)
For binary files, this special case causes issues (e.g. #3686), because it
bypasses the general work-queue logic, and any special logic for properties
does not get applied (e.g. svn:executable). This currently works for text
files, since it runs the svn_client_mergeX() process.
Just my $0.02.
Cheers,
Daniel B.
Re: Dangerous to keep re-integrated branches alive?
On Sat, Feb 12, 2011 at 1:10 PM, Varnau, Steve (Neoview) < steve.var...@hp.com> wrote: > Hi all, > > My development group uses quite a bit of branching. I’m trying to train > folks to delete a task branch once it is integrated and create a new one for > the next task. Of course the svnbook gives the recipe for “Keeping a > reintegrated branch alive”, by using a record-only merge to block the > integrated revision from being merged back to the task branch later on. > (when sync-ing up the branch) > > It has always seemed to me that that is risky. If there were changes in the > re-integration merge for conflict resolution, etc, then those changes are > also being blocked from being merged back to the (kept-alive) task branch. > Future changes on the task branch don’t include those fixes and future > re-integrations could potentially even over-write them (since the mergeinfo > data says we’re all up-to-date with respect to that prior revision). > My understanding is that this should never happen. During a reintegration merge, there is validation that all revisions from the target (normally /trunk) have been merged across into the branch - any conflict resolution is done during this merge. The reintegration merge then does a basic file compare, and merges across. After the reintegration merge, /trunk and the branch should be bit-by-bit identical. Period. If not, then either your use case for merging is a little strange, or there is a problem. Cheers, Daniel B.
Re: how to switch a WC back?
On Mon, Feb 14, 2011 at 9:15 AM, Paul Maier wrote: > Hi, > > a question about how to switch back a WC: > > I checked out a WC, and then switched some subdirectories to some other > directories. I worked with that for a while, checked in, all fine. > Now I want to switch my WC back. > > Can I automatically "un-switch" the WC? > > I mean: I could do a second switch and there I could manually specify the > URL of > the original subdir. That would work, but would mean, that I manually find > out: > - which subdirectory is in a switched state > >From 'svn help status': Fifth column: Whether the item is switched or a file external ' ' normal 'S' the item has a Switched URL relative to the parent 'X' a versioned file created by an eXternals definition > - what is the URL of the unswitched directory (how??) > SVN does not store this information - you'd need to find this out for yourself. > - manually switch back. > svn switch old_url sub_dir? > Is there a way to issue some command that does that for me automatically? > You can run switch on the parent directory (using the same URL as it currently has), and this will override any switched sub-directories. > Thanks for hints! > > Regards > Paul Cheers, Daniel B.
Re: Property change log
On Tue, Feb 15, 2011 at 5:03 PM, Daniel Widenfalk wrote: > Hi, > > A colleague of mine asked me this: "Is there an easy > way to list in which revisions a property has changed?". > After wringing my brain around the problem for a bit I > had to conceit failure. My question to the community > is therefor; How do I do the equivalent of: > > svn proplog svn:externals . > > Where proplog is an invented command that only show the > log messages for revisions that contain changes to the > given property. The command would only recurse if -R is > given on the command line. > > Best regards > /Daniel Widenfalk > I just tried it out, and I expected: svn log --depth empty to work, but 'svn log' doesn't accept the depth option. I know there's work to add an option to exclude all property changes from the log - maybe it should be structured like the '--with-all-revprop, --with-no-revprop, --with-revprop' options. Cheers, Daniel B.
Re: Subverion 1.7 Centralized Metadata Storage
On Thu, Feb 24, 2011 at 12:16 PM, Nguyen Vu Hung (VNC) < vuh...@vinicorp.com.vn> wrote: > (2011/02/22 17:18), Ulrich Eckhardt wrote: > > On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote: > > > * This way makes svn git-like :), my first impression is that: >subversion will be distributed, not centralized :) > > SVN has one .svn directory in every (versioned) child directory of a working > copy. This has the effect that every child directory of a working copy is > itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a > single place to store this. > > > This is a handy replacement for svn export function. > > Backward compatibility with 1.6 is another big concern who wants to > upgrade from 1.6 or maintaining an ecosystem of both 1.6 and 1.7 > How will this be any different from maintaining an ecosystem of 1.5 and 1.6? Cheers, Daniel B.
Re: Using SVN with cron?
On Mon, Mar 7, 2011 at 5:35 AM, bimininavels wrote: > I've been struggling all morning with what should be a very simple problem. > > I would like to commit and update a svn repository daily using cron. I've > encapsulated my svn calls into a perl script, which runs the following > > > #!/usr/bin/perl > > print "To run svn commit\n"; > $thetime=time; > > system "cd ~/docs; /usr/bin/svn commit --message '$thetime' \n"; > system "cd ~/docs; /usr/bin/svn info \n"; > > > The whole thing is >> to a file in my /tmp directory for monitoring. > > The script works fine if I run it manually. > > In the monitoring file, I see the correct output from svn info after the > cronjob, but it looks like the "svn commit" never runs. I don't see any > output > from it and the revision never changes. > > > To run svn commit > Path: . > URL: svn://xxremoved > Repository Root: svn://xxremoved > Repository UUID: xxremoved > Revision: 487 > Node Kind: directory > Schedule: normal > Last Changed Rev: 487 > Last Changed Date: 2011-03-06 04:42:01 -0800 (Sun, 06 Mar 2011) > > > (I do have some file changes there to force a commit) > > Does anyone know why svn info would work while svn commit would not? > > Thanks, > - Jonathan > Have you read the replies you got when you posted the first time? http://mail-archives.apache.org/mod_mbox/subversion-users/201103.mbox/%3c201103061145.36661...@qgenuity.com%3E Cheers, Daniel B.
Re: pre-lock.bat Failed in Repo browser
On Tue, Mar 15, 2011 at 8:25 AM, Michael Diers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2011-03-10 11:21, Michael Diers wrote: > > On 2011-03-10 08:23, Waseem Bokhari wrote: > >> This script works fine in all scenarios except Anyone can Steal Lock > when Unlock. > > > >>> Unable to Break lock through check for modifications Option > >>> Unable to break lock through Repo browser > >> BUT > >> Only any user can Steal Lock when he tried to Get Lock and > Check the below mentioned Option of Steal Lock. > > > > Waseem, > > > > I'm not following. Could you please express the scenarios in terms of > > command line client operations? (Otherwise, dedicated TortoiseSVN forums > > might be a better place to ask for assistance.) > > > > For instance, "Unable to break lock through Repo browser" translates to > > "Unable to break lock through `svn unlock --force'". > > OK, there are two ways to get rid of locks owned by some other user: > > "stealing a lock" by running `svn lock --force' > > and > > "breaking a lock" by running `svn unlock --force'. > > If you want to hook these operations, you need a pre-lock hook script > and a a pre-unlock hook script, respectively. Note that in both cases, > the fact that the user specified "--force" is not communicated to the > hook script. > > It appears you want to completely disallow "stealing" and "breaking" of > locks. So, for both hook scripts, if the calling user is not identical > to the lock owner, you want to fail the hook script. > > Does that sound about right? > In addition to this, locks are for a working-copy, not necessarily for a user. It's possible for the same user to steal the lock that they already hold in another working copy, and your script will let them. Cheers, Daniel B.
Re: baffled by how merging works
On Thu, Mar 24, 2011 at 12:03 PM, Michael Remijan wrote: > I'm fairly new to svn and I'm trying to get my head around how svn handles > branches and merging. I've done a lot of reading on this, I've been able to > work my way through merging changes from TRUNK to a BRANCH but I still do > not quite understand it. If someone could start by explaining what happens > in this scenario that would help. > > First, I used this command to see the differences between my BRANCH and > TRUNK > svn diff --summarize --old http://repo/proj/branches/1/ --new > http://repo/proj/trunk/ > > Second, based on the summary, I merged differences from TRUNK into BRANCH > and commited the BRANCH. > > Third, I re-ran the command to see if there were any changes I missed. > svn diff --summarize --old http://repo/proj/branches/1/ --new > http://repo/proj/trunk/ > > To my surprise it gave me the same summary. After merging the changes into > the BRANCH and committing the changes, I expected there to be no changes. > So why does it give me the same summary? > I think your --old and --new switches are around the wrong way. 'svn diff --summarize --old --new ' will give you the changes on the branch not on trunk, 'svn diff --summarize --old --new ' will give you the changes on trunk not yet on the branch. It seems you want the latter. Cheers, Daniel B.
Re: RFE: Add Subversion keyword for year
On Tue, Apr 19, 2011 at 7:29 AM, Alex Vincent wrote: > I'm currently in the process of updating copyright notices where I work. > To me, this is an ideal place for a SVN keyword: > > Copyright 2008-$Year$ MyCompany > > The SVN keywords listed in the online documentation list Date, but it's far > too specific for a copyright. As an alternate, perhaps a special formatting > keyword for dates could be established: $Date()$, for example. > AFAIK, the $Date keyword works off the last time the particular file was updated. Are you expecting this new $Year$ value to always be current (ie 2011), or only reflect the year in which the file was last modified (ie 2009)? Cheers, Daniel B.
Re: svn update by version not updating correctly
On Thu, Jun 2, 2011 at 8:51 AM, Norman Morse wrote: > I have a subversion repository with these log entries: > > & svn log --verbose -r 2431:2433 > > r2431 | cchan | 2007-08-25 08:11:43 -0700 (Sat, 25 Aug 2007) | 1 line > Changed paths: > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClient/Service/HTTPServiceLocator.cs > > CC - PGPS - Fix TestBench build error. HACK ConfigurationManager into > HTTPServiceLocator. > > > r2433 | cchan | 2007-08-26 12:30:24 -0700 (Sun, 26 Aug 2007) | 1 line > Changed paths: > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClient/PGPSClient.csproj > D > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClient/Util > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/GUI/PGPSClientForm.cs > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/GUI/PGPSClient_PerfTest.cs > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/GUI/ServiceManagementForm.cs > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/OrbitPropagationLayerTask.cs > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/PGPSClientUI.csproj > M > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/ServiceLayerTask.cs > A > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/Util > A > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/Util/Patterns > A > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/Util/Patterns/Observer > A > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/Util/Patterns/Observer/IObservable.cs > A > /rxnetworks/apps/gpstream/pgps/PGPSClient_WinMobile/trunk/PGPSClientUI/Util/Patterns/Observer/IObserver.cs > > CC - PGPS - Moved Observer pattern from PGPSClient to PGPSClientUI > > > When I try to step through these revisions using update I get: > > & svn update --set-depth infinity -r 2432 > UPGPSClient.csproj > AUtil > AUtil/Patterns > AUtil/Patterns/Observer > AUtil/Patterns/Observer/IObservable.cs > AUtil/Patterns/Observer/IObserver.cs > AUtil/RXNSyntheticData.cs > AUtil/RXNStateVectorData.cs > AUtil/SvnToPrnMap.cs > AUtil/DateTimeUtil.cs > > & svn update --set-depth infinity -r 2433 > DUtil > Updated to revision 2433. > > Why are all the other adds in 2433 ignored? > Since Util is added back in after the delete, I would think that Util and > it's children Added > in this step would be restored, but I only get an empty directory. > I'm guessing it's because you're running the 'svn update' from within the 'PGPSClient' folder, whereas all the "A"dd actions happened on the PGPSClientUI folder (it's sibling). Cheers, Daniel B.
Re: copy tag shows repo revision, not tag revision - why?
On Sun, Sep 11, 2011 at 6:09 AM, sebb wrote:
> When copying a tag (URL -> URL), the log message shows the repo
> revision at the time of the copy, rather than the last commit revision
> of the tag.
>
> This occurs if no revision is specified, or if the revision is
> specified as HEAD.
>
This is correct. The copy operation is copying the tag as it appeared at the
revision specified (ie HEAD), not as at the last commit revision. In your
case, there's no difference.
> The only way to get the log message to show the last commit revision
> of the tag seems to be to specify it on the svn copy command; this is
> tedious and error-prone.
>
> Is there any simpler way to ensure that the log message shows the last
> committed version of the source tag?
No. You can look at the history of the tag ('svn log') to see what the last
change on the source was, though. I'm confused as to why the source copy
revision matters.
Cheers,
Daniel B.
Re: Getting error when trying to upgrade to version 1.7
On Tue, Oct 18, 2011 at 1:14 AM, Paul wrote: > I upgraded TortoiseSVN to version 1.7 (I'm on Windows 7 x64) and it said > that I needed to upgrade the format of my files. I told it to go ahead but > it errored out. > > I rebooted, did a Cleanup first and then ran it again. Same error: > > --- > In file > > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c' > line 1935: assertion failed (svn_checksum_match(entry_md5_checksum, > found_md5_checksum)) > --- > > Any ideas? > > I'm using Beanstalk hosting for the server. > http://www.lmgtfy.com/?q=svn-users+line+%221935%3A+assertion+failed%22
Re: Cherry-picking revision to merge.
On Mon, Oct 31, 2011 at 10:18 AM, Gavin "Beau" Baumanis < gavin.bauma...@palcare.com.au> wrote: > Hi Everyone, > > I hoping that I can get some help with the theory of cherry-picking merges > to a branch. > > I have the "default" subversion layout; > /trunk > /branches > /tags > > I have a "release branch"; ^/branches/releases/1.5 > > I have "^/trunk/filename.txt" > I have just created a release branch, made some changes and created a tag > for release. > ^/tags/1.5 > > The repo revision is @100. > > A colleague makes a some changes, so no filename.txt is @r101. > I make a critical bug fix (unrelated to r101) and now > "^/trunk/filename.txt" is at r102. > > I want to a make a "point" release, so as to get the bug-fix out to > customers. > But the changes made at r101 are not ready for release, yet. > > How do I go about getting "just" the changes made in > "^/trunk.fiename.txt@102", merged into the release branch? > svn merge -c 102 ^/trunk .? Cheers, Daniel B.
SVN, VMware and veeam replication
Hi, We're currently looking at moving our SVN repositories off of a Windows 2003 physical machine to a 2008 VM (in VMWare vCentre). This is to allow easier replication to our DR site through the veeam replication software. Has anyone done this before, and if so, are there any gotchas that we need to be aware of? Is there any particular settings that we need to switch on/off for either the vCemtre or Veeam? Cheers, --- Daniel Becroft
SVN 1.7 repository + Jenkins
Hi, We're testing upgrading our SVN repositories to 1.7 format, and have noticed something a bit strange. In Jenkins (1.441), I can set the SVN URL to checkout from, and it validates whether it is correct. With a 1.7 repository, however, it doesn't seem to validate correctly (error is "/trunk/foo doesn't exist in the repository"). I'm not sure exactly what command it is using to connect/validate, but from the svnserve logs, I can see the following: Subversion 1.6: 1236984 2011-12-07T02:15:56.090125Z 192.168.30.145 - repos open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/foo - - 1236984 2011-12-07T02:15:56.090125Z 192.168.30.145 - repos get-latest-rev 1236984 2011-12-07T02:15:56.090125Z 192.168.30.145 - repos check-path /trunk/foo@3 1236984 2011-12-07T02:15:56.105750Z 192.168.30.145 - repos open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/foo - - 1236984 2011-12-07T02:15:56.105750Z 192.168.30.145 - repos get-latest-rev 1236984 2011-12-07T02:15:56.105750Z 192.168.30.145 - repos check-path /trunk/foo@3 Subversion 1.7: 7232 2011-12-07T02:27:43.779133Z 127.0.0.1 - svnrepos open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/foo - - 7232 2011-12-07T02:27:43.779133Z 127.0.0.1 - svnrepos get-latest-rev 7232 2011-12-07T02:27:43.779133Z 127.0.0.1 - svnrepos check-path /trunk/foo/trunk/foo@2 7232 2011-12-07T02:27:43.794758Z 127.0.0.1 - svnrepos open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/foo - - 7232 2011-12-07T02:27:43.794758Z 127.0.0.1 - svnrepos get-latest-rev 7232 2011-12-07T02:27:43.794758Z 127.0.0.1 - svnrepos check-path /trunk/foo/trunk@2 7232 2011-12-07T02:27:43.794758Z 127.0.0.1 - svnrepos check-path /trunk/foo/trunk/foo@2 The 1.7 repositories were created with svnadmin create/svnsync, rather than a dump/load cycle. Using the same version of Jenkins (and SVN client), it seems that the check-path lines are incorrect for 1.7 (it's doubling up). I can successfully checkout the repositories from both servers. We've also noticed some similar messages appearing with Subclipse, but these appear to be sporadic. Any ideas? --- Daniel Becroft
Re: Subversion 1.6.9 Released
On Fri, Jan 22, 2010 at 8:56 AM, Hyrum K. Wright < hyrum_wri...@mail.utexas.edu> wrote: > I'm happy to announce Subversion 1.6.9, available from: > >http://subversion.tigris.org/downloads/subversion-1.6.9.tar.bz2 >http://subversion.tigris.org/downloads/subversion-1.6.9.tar.gz >http://subversion.tigris.org/downloads/subversion-1.6.9.zip >http://subversion.tigris.org/downloads/subversion-deps-1.6.9.tar.bz2 >http://subversion.tigris.org/downloads/subversion-deps-1.6.9.tar.gz >http://subversion.tigris.org/downloads/subversion-deps-1.6.9.zip > > (Please note that Subversion 1.6.7 and 1.6.8 were never publicly released.) > Hi, Just curious, with the move to the ASF, what impact does that have on the release of compiled binaries (e.g. for windows) for future Subversion releases? Are these still done by volunteers, or is there the capability for providing 'official' binaries as well? I notice that there are several projects on the ASF that provide windows binaries, but I am not sure if they are done by volunteers or not. Cheers, Daniel B.
Re: Programming a Watcher File
On Wed, Mar 3, 2010 at 2:26 AM, David Weintraub wrote: > One of the tech leads wants to be able to program a watch file, so > that when a certain set of developers change a particular file, > certain other developers get notified. Thus, we need to be able to > program what files, what developers do the commit, and what developers > receive the notification. I'd like to do this, so this developer can > maintain this file himself instead of me having to maintain it which > means it can't be a text file on the Subversion server. > > I'm working with something like this now. I have a configuration file > where you setup the various parameters (specifying files via globbing > or regex), who does the commit, and who receives the email. The > configuration file sits in the source repository, so this tech lead > has access to it. > > I was wondering if anyone already has a post-commit hook script like > this already setup. I know there's one included in Subversion, but > this one uses a text file that's accessible to the hook script and its > setup isn't that flexible. > > If not, I'll finish up the one I'm working on. > > Probably a bit too late now, but have you considered using a tool such as CommitMonitor, or SVNNotifier? Cheers, Daniel B.
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 10:08 AM, Vadym Chepkov wrote: > Hi, > > I know, this is maybe not the best practice, but, unfortunately, our > subversion users do this all the time: they merge form one branch to another > back and forward. > The question is, how to properly do it without introducing conflicts. > Here is the test case, which one would think should be handled properly, > but for some reason it's not: > > [~]$ svnadmin create mergerepo > [~]$ svn co file://`pwd`/mergerepo mergework > Checked out revision 0. > > [mergework]$ svn mkdir --parents branches/b1 > A /home/vvc/mergework/branches > A /home/vvc/mergework/branches/b1 > > [mergework]$ svn commit -m "Created branch b1" > Adding branches > Adding branches/b1 > > Committed revision 1. > > [mergework]$ svn copy branches/b1 branches/b2 > A branches/b2 > [mergework]$ svn commit -m "Created branch b2" > Adding branches/b2 > > Committed revision 2. > > > [b2]$ touch README > [b2]$ svn add README > A README > [b2]$ svn commit -m "Added README" > Adding b2/README > Transmitting file data . > Committed revision 3. > > > [b1]$ svn merge -c 3 ^/branches/b2 > --- Merging r3 into '.': > AREADME > [b1]$ svn commit -m "Merged r3 into b1" > Sendingb1 > Adding b1/README > > Committed revision 4. > [b2]$ svn merge --dry-run ^/branches/b1 > --- Merging r2 through r4 into '.': >C README > Summary of conflicts: > Tree conflicts: 1 > After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2->b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B.
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov wrote: > > On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: > > > > [b2]$ svn merge --dry-run ^/branches/b1 >> --- Merging r2 through r4 into '.': >>C README >> Summary of conflicts: >> Tree conflicts: 1 >> > > > After r3, you'll need to do a '--record-only' merge of r4 into the second > branch: > > (untested) svn merge --record-only -c 4 ^/branches/b1 > > SVN doesn't seem to trace back through the commits to see that r3 was > really a merge from b2->b1. Like yourself, I initially though that it would > be able to deal with this, but it doesn't seem to (and there is probably a > very good reason why it can't). > > Cheers, > Daniel B. > > > Well, as you can see in the log, it also wants to merge r3 back, not just > r4, so we would have to "record-only" 2 of them, it seems. > I'm pretty sure that you only need to do a record-only of r4. If you do a 'svn merge -r 2:3 ^/branches/b1, I don't think it will actually do anything (other than modify the mergeinfo property). When I get a chance, I'll run a quick test on it (or if you have the WCs from the above example, you could try it yourself). > The problem is, we utilize a "home made" automerge utility that constantly > merges all changes from b1 to b2, > but merges from b2 to b1 are done manually. After r4 is committed, it > produces conflict for automerge immediately and this is what I am trying to > avoid. By the way, maybe there is an intelligent automerge utility out > there that can handle this kind of things, if anyone knows. > You could check if r4 contains mergeinfo for b2, and if so, don't worry about doing the merge between b1->b2, or force it to be record-only. Cheers, Daniel B.
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud wrote: > Like yourself, I initially though that it would be able to deal with this, >> but it doesn't seem to (and there is probably a very good reason why it >> can't). >> > > I would be interested in knowing this "very good reason why it can't". I'm > not questioning its validity, I'm confident this good reason is a good > reason, but as I was surprised too by this behavior, if someone could give > an explanation? I would be very interested. > After thinking more about it, I believe it's because a revision can contain more than just the merge. For example, if I merge r10 from into a branch, I don't have to commit just that merge. I can have modifications in my working copy, merge, make more modifications, and commit in r11. The svn:mergeinfo will attest that r10 from trunk has been merged in this revision, but it doesn't mean that r11 on the branch is the logical equivalent of r10 on the trunk. I think that best practices suggest that doing things in this manner is a bad idea, and should be discouraged. A revision that contains svn:mergeinfo changes should only contain the file and structure changes logically equivalent to the revisions that have been merged. Cheers, Daniel B.
Re: Cherry-picking merges
On Fri, Apr 30, 2010 at 10:52 PM, Greg Troxel wrote: > > Daniel Becroft writes: > > > On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud > wrote: > > > >> Like yourself, I initially though that it would be able to deal with > this, > >>> but it doesn't seem to (and there is probably a very good reason why it > >>> can't). > >>> > >> > >> I would be interested in knowing this "very good reason why it can't". > I'm > >> not questioning its validity, I'm confident this good reason is a good > >> reason, but as I was surprised too by this behavior, if someone could > give > >> an explanation? I would be very interested. > > The problem is that you have to commit on two branches at once. The > workflow is (very roughly): > > go onto merge target branch > svn merge source branch > svn commit => making C > > switch to source branch > svn merge -c $C --record-only target-branch > svn commit > > We ended up writing scripts to do both of these things, which worked > because we had a structured repository. > We've only just started using feature branches, and most of the time, our merges are one way (trunk -> branch), until, eventually, we need to reintegrate (or just dump the branch). One the few occasions that a branch -> trunk is required, we just do it manually. Less work for something that is fairly rare (for us). > A better fix would be to have commit C be marked as merge-from-source in > some sort of commit property and to have merge to a branch omit > changesets that are being merged back to that branch. This is exactly what the svn:mergeinfo property is for. But, the downside is that it records when rX from branchA was merged in rY of branchB. As below, it does not state that rY on branchB is the logical equivalent of rX. > But this has to > be carried along so when you merge from A to B to C and merge C back to > A you don't redo the A commits. So the bookkeeping is hard, but I think > that's what it takes. Implementing this might or might not be easier > than training everyone how to use Git :-) > See above. The merge to C will contain a modification to svn:mergeinfo that contains details of branch A and branch B. > > > For example, if I merge r10 from into a branch, I don't have to commit > just > > that merge. I can have modifications in my working copy, merge, make more > > modifications, and commit in r11. The svn:mergeinfo will attest that r10 > > from trunk has been merged in this revision, but it doesn't mean that r11 > on > > the branch is the logical equivalent of r10 on the trunk. > > > > I think that best practices suggest that doing things in this manner is a > > bad idea, and should be discouraged. A revision that contains > svn:mergeinfo > > changes should only contain the file and structure changes logically > > equivalent to the revisions that have been merged. > > Absolutely. This isn't a "clean changeset" and is madness; everyone > should prohibit it. > Completely agree. Cheers, Daniel B.
Re: Size of SVN Transaction vs Actual commit size
On Fri, May 7, 2010 at 8:26 PM, Ravi Roy wrote: > > > On Fri, May 7, 2010 at 3:33 PM, Olivier Sannier wrote: >> >> Ravi Roy wrote: >>> >>> Actual commit size is 1.28 MB and this script gives me 5528 bytes. >>> Something wrong with script or there is compression involved or what ? >> >> Well, reading the book could have told you that this is expected: >> >> >> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas > > > > Thanks Olivier; but this is just abstract view; I want to compute the > transaction size based on some predefined value (say 5 MB) and allow commit > to the repository if transaction size (in case new file commit) is less than > or equal to this size. Have a look into 'svnlook changed' and 'svnlook cat' commands. Cheers, Daniel B.
Re: How to change default svn-commit.tmp contents
On Thu, May 20, 2010 at 10:08 AM, Bostjan Skufca wrote: > Hi all! > > I would like to change default contents of commit message from 'svn status' > output to add 'svn diff' output. How can this be achieved? > > I have already tried setting editor-cmd in ~/.subversion/config to "svn diff >>> svn-commit.tmp && mcedit" and it partially works, but creates diff > against previous revision, not HEAD. > > Any suggestions? 1) Try running an update first. 2) If you're committing a file, and the diff between the working copy and previous is not identical to the diff between working and HEAD, that would indicate an out of date working copy, and I would expect you should get an error. 3) Can I ask why you are trying to include the diff in the log message? Cheers, Daniel B.
Re: How to change default svn-commit.tmp contents
On Thu, May 20, 2010 at 10:40 AM, Bostjan Skufca wrote: > I should have known that the first thing to surface would be "why" and not > "the answer". But your question, Daniel, was polite at least :) > > If you pay attention to the command line in editor-cmd setting you can > notice that content is appended. Therefore it is positioned below the -- > This line and everything below... > There are times when changes to certain files are accumulating over the days > and when I hit "svn ci" I would like to get a glimpse of those changes. Of > course you can do it in another terminal, and for larger changesets I > definitely do so. But for smaller changesets it is just very convenient to > see right away what was changed. Ah, good point. I don't use the command-line to commit, so wasn't aware of this. > Now, the 'update-first' seemed reasonable but it does not solve the issue. > Will look deeper into it tomorrow. How did the update-first not solve the issue? What is the diff producing and what are you expecting? Is it different or the same as running a standard 'svn diff' from the command-line. As I understand it, the revisions specified in the diff output (ie on the '---' and '+++' lines) should be the revision currently checked out (ie reported by the 'svn update'). I've never seen (revision HEAD) specified in the diff output, since HEAD is continually a moving target. > Thanks for your assistance, > b. > > > > > On 20 May 2010 02:17, Daniel Becroft wrote: >> >> On Thu, May 20, 2010 at 10:08 AM, Bostjan Skufca wrote: >> > Hi all! >> > >> > I would like to change default contents of commit message from 'svn >> > status' >> > output to add 'svn diff' output. How can this be achieved? >> > >> > I have already tried setting editor-cmd in ~/.subversion/config to "svn >> > diff >> >>> svn-commit.tmp && mcedit" and it partially works, but creates diff >> > against previous revision, not HEAD. >> > >> > Any suggestions? >> >> 1) Try running an update first. >> >> 2) If you're committing a file, and the diff between the working copy >> and previous is not identical to the diff between working and HEAD, >> that would indicate an out of date working copy, and I would expect >> you should get an error. >> >> 3) Can I ask why you are trying to include the diff in the log message? >> >> Cheers, >> Daniel B. > >
Re: Automatic commission?
On Tue, May 25, 2010 at 7:40 AM, Peng Yu wrote: > It seems that I have to specify which file or files to commit. This > will be a problem if I always simultaneously edit tens of files before > I can do a commission. Is there an automatic way to figure out which > files should be commit and commit them? You can not specify anything, and it will commit all changes (e.g. svn commit -m ). See the book for an example: http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.commit Cheers, Daniel B.
Re: Strange status if .svn folder removed
On Thu, May 27, 2010 at 7:06 AM, Steve Armstrong wrote: > Hello all, > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 > command-line binaries. > > I have a working copy checked out (C:\wc). Inside it, there's an empty > folder that's source-controlled (C:\wc\logs). If I delete the .svn folder > from within logs, then doing an "svn st" in the base folder (C:\wc) gives > me: > > C:\wc>svn st > ~ log > According to the help, '~' means: versioned item obstructed by some item of a different kind. In other words, the normally versioned 'log', is blocked by the (now) unversioned 'log'. Removing the .svn folders mean that SVN cannot determine anything else about this folder. > Trying to update to "bring back" the folder shows a delete: > C:\wc>svn up > Dlog > Updated to revision 200374. > This is probably the only unexpected result from the commands so far. > The folder is still there, without a .svn folder inside it, and svn doesn't > know what to do with it. > C:\wc>svn st > ? log > Now SVN knows the folder is unversioned ... > At this point, the repository still shows the folder (the delete didn't > happen on the server). After deleting the log folder, svn thinks > everything's fine (even though the folder is now totally missing from the > working copy) > > C:\wc>svn st > > Reverting the folder to bring it back does nothing: > C:\wc>svn revert log > Skipped 'log' > ... and because it's unversioned, revert does nothing. > Doing a general update doesn't work: > C:\wc>svn up > At revision 200376. > > Only by doing an update directly to log can I get the folder back: > C:\wc>svn up log > Alog > Updated to revision 200376. > > There are reasons that I probably shouldn't have this skeleton under source > control in the first place, but this seems like broken behavior regardless. > Should I file it as a bug? Or is it already known? > The moral of the story, is to not mess with the .svn folders. Cheers, Daniel B.
Reintegrate w/ previous --record-only merges
Hi, I've just come across an interesting scenario, which did not work as I expected. I created a feature branch several months ago, and have been keeping it up to date from trunk periodically. There was a change towards the start that was required on the branch, but I did not want merged into trunk. Ever. So, I performed a record-only merge of that change into trunk. This change affected only two files, neither of which had additional changes to it (other than non-conflicting merged changes from trunk). It's getting to the point that I need to reintegrate this branch back into the trunk, so I did a test on it today. It seems that using the '--reintegrate' option of the merge command does not honour the previous mergeinfo that is present. These changes are still coming across in the merge. In short, the steps were: - Create feature_branch from tr...@r100 - Make change to alpha.txt and beta.txt in feature_branch in r105 (not to be merged back) - Perform record-only merge from feature_branch to trunk in r106 - Perform sync merge from trunk to feature_branch in r110 - Perform reintegrate merge from feature_branch to trunk (alpha.txt and beta.txt are showing as contents-modified) I'm going to try and knock up a reproduction recipe tomorrow, but I first wanted to check whether this was expected behavior. I know changes can be cherry-picked to be merged from the branch back to trunk, and the reintegrate process will 'ignore' these. But, can changes be cherry-picked *for exclusion* from a reintegrate merge? Or does reintegrate ignore the mergeinfo? Cheers, --- Daniel Becroft
Re: Wanted: pre-commit hook to prevent commits to externals definition
On Fri, Jun 4, 2010 at 12:12 AM, David Aldrich wrote: > Hi > > Please can anyone point me to an example of a svn pre-commit hook that > prevents commits to files that are members of an externals definition? > > We want to allow such files to be committed only from within the external > directory, i.e. where they originate from. > > Best regards > > David > I don't have an example of such a script. *But*, I'm not sure if even such a script could be possible. My understanding of committing w/ externals, is that the modifications to the externals are committed separately (or even excluded) from the main commit. This would certainly be the case for externals pointing to a separate repository, and may be the case . I just did a quick test (with both intra- and inter-repository external definitions), and SVN does not seem to descend into the externals for a commit. The externals directory has to be explicitly committed, which makes it no different from a normal working copy. Cheers,
Re: Wanted: pre-commit hook to prevent commits to externals definition
On Mon, Jun 7, 2010 at 6:52 PM, Lorenz wrote: > David Aldrich wrote: >>Please can anyone point me to an example of a svn pre-commit hook that >>prevents commits >>to files that are members of an externals definition? >> >>We want to allow such files to be committed only from within the external >>directory, i.e. where >>they originate from. > > As long as the externals are pointing to the same repository it should > be possible to examine the transaction and determine if any of the > changed paths is related to an external definition (external > properties can be extracted from the transaction too). Really? From my testing, it seemed that SVN doesn't descend into externals during a commit, regardless of whether the external points to the same or a different repository. Have you seen different behaviour? Cheers, Daniel B.
Re: can I use svn:externals instead of svn copy to create a tag?
On Fri, Jun 11, 2010 at 6:42 AM, Gary Hallmark wrote: > All examples I have seen for tagging use svn copy (or svncopy -tag) to > create a tag. If I want to make sure nobody can change the tag, I guess I > could write a commit hook. But couldn't I use a versioned external > definition to create the tag instead of svn copy? Seems this would better > enforce that nobody can change the tag, since it isn't a copy at all. One > downside would be that if the tag contains unversioned externals, I would > not be able to pin them down, but I don't plan to have unversioned > externals. Are there any other downsides? > > Example: > trunk/ > tags/ > X -r123 ^trunk version_1.0 You would still need to enforce (via a commit hook) that no-one can modify the version_1.0 external definition to point to -r456 instead. Not sure how much simpler (or more difficult) this would be over having standard folders. BTW, I think the definition you might want to use is ^tr...@123, rather than -r123 ^trunk, but I could be wrong. Cheers, Daniel B.
Re: Applying multiple commits done to a branch to another branch
On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer wrote: > >> You're describing a normal usage of merging. >> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html >> >> You don't want to redo all those commit messages, you want the merge >> to be aware of the history behind everything that's been done (which, >> if you're using 1.5 or later, is taken care of), so that svn log can >> trace back & all those messages fall right in line. > > Really... I didn't know this happened. If you look at the log of trunk where > you have merged in from branch won't it only show the merge as a single rev > with the message you made in the merge commit. How will you be able to trace > the log back through the changes made in branch? It does, but not by default. You need to use the '-g/--use-merge-history' switch. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.logblame Cheers, Daniel B.
Re: Why am I getting a bad merge?
On Sun, Jun 20, 2010 at 2:24 AM, Steven Boswell II wrote: > (I asked this question almost a month ago on the users list, but got no > response, so now I'm trying the developers list.) Developers list is not an escalation point of the users@ list. Moving back to the users@ list now ... > I recently began using Subversion to track a project at the new company where > I work. We've been using it for a few weeks, and our database has just over > 60 commits to it now. > > I created a "release" branch of the project at revision 36, and have been > doing heavy development in the trunk, merging only the bug fixes into the > branch. It now looks like my trunk changes are fine, and I wanted to merge > them into the release branch, but that's where things went wrong. Most of > the files were fine, but one file missed a very large change! > > In the branch, that file had a change at revision 62, and as mentioned above, > the branch was created in revision 36. In the trunk, that file was modified > in revisions 61, 59, 37, 23, and points earlier. The single merge of that > file into the branch was done with "svn merge -r61:62 ", run on the > parent directory. When I try to merge the trunk version of that file into > the branch, I get: > > --- Merging r47 through r62 into '': > U Are you trying to merge on that path explicity, or still merging on the parent directory? > As you can see, it skips the change to the file made in revision 37! > Specifying "-r36:62" in the command line gives the same result. I'm not even > sure why it's mentioning revision 47, because the file wasn't changed then. > > "svn propget svn:mergeinfo --depth infinity " shows nothing, not > even the merge from "-r61:62". What is the output from the from the following commands: svn mergeinfo --show-revs merged branch_folder svn mergeinfo --show-revs merged branch_file These will tell you (in a more readable format) the revisions that SVN belive have already been merged. svn mergeinfo --show-revs eligible branch_folder svn mergeinfo --show-revs eligible branch_file These will list the revisions that SVN thinks are available to be merged. If r37 is not being merged, then it should be listed in one of the first two commands.
Re: How to find who commits the build and revision number?
On Thu, Jun 24, 2010 at 1:36 PM, David Weintraub wrote: > On each and every Hudson build webpage is the Subversion repository > revision number. You can use that and "svn log" to see who did the > commit that triggered that build. Hudson also grabs the log information for the revisions on each update, and displays these under the "Recent Changes" link on the project page, or the "Changes" page for each build. Cheers, Daniel B. > On Wed, Jun 23, 2010 at 12:55 AM, Kevin Wu wrote: >> Hi folks, >> >> I am using Hudson + Subversion to automate the build process. >> >> Everybody triggers the hudson build process is "anonymous". And I don't want >> to add extra authentication to Hudson. >> >> So I want to know if it is possible to get information from Subversion about >> who commits the change to the svn repository, and the revision number of >> that commit. >> >> THANKS IN ADVANCE. >> >> -- >> Best wishes, >> Kevin Wu >> > > > > -- > David Weintraub > qazw...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@hudson.dev.java.net > For additional commands, e-mail: users-h...@hudson.dev.java.net > >
Re: .svn-revert files under .svn/prop-base directory ...
On Fri, Jun 25, 2010 at 4:42 AM, wrote: > Thanks so much for your quick response. > > I'm not sure I understand what you're saying. :-( When would a > file.svn-revert file be created for the "file" example below? On a merge? A > regular commit following modifications? Does anything in the logs > distinguish these files? And would I expect the file.svn-revert file to be > there for the life of the working copy? In the example below, the .svn-revert file gets created as a result of either of the 'svn cp' operations. It represents what 'file' looked like before the 'svn rm file' command. Normally, the .svn-base file represents 'file' exactly as it exists in the repository at the point of checkout/update. It is this .svn-base file is used when performing an 'svn revert'. However, the 'svn cp' command changes the .svn-base to be that of the copy-source. The .svn-revert is the original base of the file that was removed. For example: svn checkout > creates file.svn-base svn rm file svn cp other-file file <<-- copies file.svn-base to file.svn-revert, and other-file.svn-base to file.svn-base AFAIK, the .svn-revert will only be there whilst the revert action is possible. Once you perform either 'svn commit' or 'svn revert', the .svn-revert file will be removed (since .svn-base is sufficient). Interestingly, the .svn-revert file under prop-base is *always* created, even if there was no previous .svn-base file. Disclaimer: I'm not a Subversion developer - I'm sure someone here can explain it much clearer than I. :-) > -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: Thursday, June 24, 2010 1:37 PM > To: Ring, Nolan; users@subversion.apache.org > Subject: RE: .svn-revert files under .svn/prop-base directory ... > >> -Original Message- >> From: ring_no...@emc.com [mailto:ring_no...@emc.com] >> Sent: donderdag 24 juni 2010 14:43 >> To: users@subversion.apache.org >> Subject: .svn-revert files under .svn/prop-base directory >> ... >> >> All, >> >> I'm wondering under what circumstances does a .svn-revert >> file get created under the .svn/prop-base directory. > > When a file is replaced by a different file, where that last file has an > history. In this case wc-1.0 needs one additional level of history. > > E.g. > svn rm file > svn cp other-file file > or svn cp u...@rev file > > This feature was actually added in Subversion 1.4. Before that you would get > an error that you had to commit the delete before adding a new file with > history. > > (And in Subversion 1.7 this will be handled in a completely different way as > part of the WC-NG work) > > Bert > > > >
'svn switch' and already switched dirs
Hi, In a couple of working copies, we have the following setup: /release-1.0.0.1 (checked from /branches/release/release-1.0.0.1) /alpha/beta /alpha/gamma -> (switched to /trunk/alpha/gamma) /alpha/delta /alpha/delta/epsilon -> (switched to /trunk/alpha/delta/epsilon) If I run 'svn switch '/branches/release/release-1.0.0.2' from the root directory), I would expect SVN to leave the already existing switched directories alone. However, it switches all directories (so /alpha/gamma is now switched batch to /branches/release ... ) Is this expected? Is there a switch to prevent this from occurring? And, yes, I know that externals could be used for this as well, and if we can't work around the above issue, then we might need to go to that. Cheers, --- Daniel Becroft
Re: Why is --reintegrate neccessary?
On Tue, Jun 29, 2010 at 6:56 PM, Tino Schwarze wrote: > Hi Olivier, > > On Tue, Jun 29, 2010 at 10:18:31AM +0200, Olivier Sannier wrote: > >>> I've had a discussion with a collegue yesterday and he wondered why >>> --reintegrate is neccessary for reintegration merges at all. He supposed >>> SVN should be able to determine that the intended merge is a reintegrate >>> by looking at the mergeinfo. >>> >>> So, this is just a question out of curiousity: Why is it neccessary to >>> specify --reintegrate? Or: In which case would a potential >>> auto-detection fail? > >> As always, the book is here for you: >> >> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate > > I read that, but failed to understand why the mergeinfo-Properties set > on the branch do not suffice to figure out what to reintegrate... The critical paragraph is this one: "When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)" > Given a very simple repo with three revisions like that: > > /trunk/file (r2) > /branch/bla/file (r4, mergeinfo in r3: Merged /trunk/@1-2) > > If I ran "svn merge /branch/bla" it's possible to detect that r3 is the > result of a merge, so only r4 needs reintegration into trunk. Actually, I think if you ran that at the moment, r3 would still try to be merged back into trunk (and conflicts would result). I could be wrong. > Note that I'm not questioning the existence of the --reintegrate option, > I just want to understand the particular case which made it neccessary > in the first place. > > Thanks, The problem comes where the actual contents of the merge revision (r3) does not equal the original revision contents (r1-2), most often due to merge conflicts. I can't think of an example off the top of my head, but it certainly does happen. Cheers, Daniel B.
Re: Reverse merge - Halted due to an unexpected erro
On Tue, Aug 31, 2010 at 8:43 PM, Bert Huijben wrote: > > > > -Original Message- > > From: Stefan Sperling [mailto:s...@elego.de] > > Sent: dinsdag 31 augustus 2010 12:22 > > To: Daniel Becroft > > Cc: subversion > > Subject: Re: Reverse merge - Halted due to an unexpected erro > > > > On Tue, Aug 31, 2010 at 12:54:00PM +1000, Daniel Becroft wrote: > > > Hi all, > > > > > > I've just tried to reverse-merge a revision, and I've received the > > following > > > message: > > > > > > svn merge -c -9654 .../tools tools > > > > > > BEGIN CONSOLE OUTPUT - > > > This application has halted due to an unexpected error. > > > A crash report and minidump file were saved to disk, you can find > > them here: > > > C:\Users\x\AppData\Local\Temp\14\svn-crash-log20100831124530.log > > > C:\Users\x\AppData\Local\Temp\14\svn-crash-log20100831124530.dmp > > > Please send the log file to users@subversion.apache.org to help us > > analyse > > > and solve this problem. > > > > > > NOTE: The crash report and minidump files can contain some sensitive > > > information > > > (filenames, partial file content, usernames and passwords etc.) > > > - END CONSOLE OUTPUT - > > > > > > I can replicate this very easily with a fresh checkout, and it isn't > > > revision specific (I've tried another revision and received the same > > error). > > > > > > > > > My environment is: Windows Server 2008 R2 (64-bit), svn 1.6.12 > > (SlikSVN) x64 > > > > > > svn, version 1.6.12 (SlikSvn/1.6.12) X64 > > >compiled Jun 22 2010, 21:00:12 > > > > > > Copyright (C) 2000-2009 CollabNet. > > > Subversion is open source software, see http://subversion.tigris.org/ > > > This product includes software developed by CollabNet ( > > > http://www.Collab.Net/). > > > > > > The following repository access (RA) modules are available: > > > > > > * ra_neon : Module for accessing a repository via WebDAV protocol > > using > > > Neon. > > > - handles 'http' scheme > > > - handles 'https' scheme > > > * ra_svn : Module for accessing a repository using the svn network > > protocol. > > > - with Cyrus SASL authentication > > > - handles 'svn' scheme > > > * ra_local : Module for accessing a repository on local disk. > > > - handles 'file' scheme > > > * ra_serf : Module for accessing a repository via WebDAV protocol > > using > > > serf. > > > - handles 'http' scheme > > > - handles 'https' scheme > > > > > > The strange thing is, everything works on my Windows XP Pro > > workstation with > > > 32-bit. > > > > I'm not a windows expert, but this looks like a problem with > > 64bit/32bit > > library mismatches. SlikSvn reports itself as 64bit, but the crashdump > > shows that quite a few *32.dll files are loaded -- is that normal? > > The system32 directory on Windows contains the 64 bit files, so it loads > the > right files. (The 32 bit files are in the SYSWOW32 directory, which some 32 > bit applications might see as if it is SYSTEM32 directory if they have a > compatibility shim). > > The dump file (.dmp) of this crash doesn't contain useful information. (The > stack trace it contained is from after the actual crash). The .log file > looks similar to one I recently noticed on another subversion mailing list > (Not sure which though). It might be useful to review the mergeinfo to > string functions. Thanks for looking at it Bert/Stefan. If it helps, there is no svn:mergeinfo property on this value (on any of the checked-out parent directories). The revision that I am trying to reverse-merge is from the directories direct history (it's only about 5 revisions less than HEAD, or it was at that point). I think we might have an x64 machine with TSVN 1.6.x installed on it, so I'll try and see if that fails as well. Cheers, Daniel B.
Re: Transaction and revision numbers
On Mon, Sep 6, 2010 at 7:29 PM, Giulio Troccoli < giulio.trocc...@uk.linedata.com> wrote: > Is there a special format of a transaction number? > > I would like to write a method in perl that gets a number, either > transaction or revision, and then adds the correct --revision or > --transaction parameter (for the svnlook command). So if there is a special > format for a transaction number I can use a regular expression to check it. > The difference between a transaction and revision number depends purely on context. AFAIK, the only time a transaction number is available is within a pre-commit hook - once the transaction has been committed, it's a revision number. What context would your script be run in? Cheers, Daniel B.
Re: Transaction and revision numbers
On Mon, Sep 6, 2010 at 7:57 PM, Giulio Troccoli < giulio.trocc...@uk.linedata.com> wrote: > > > > > > > Linedata Limited > Registered Office: 85 Gracechurch St., London, EC3V 0AA > Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 > > ____________ > > > >From: Daniel Becroft [mailto:djcbecr...@gmail.com] >Sent: 06 September 2010 10:52 >To: Giulio Troccoli >Cc: users@subversion.apache.org >Subject: Re: Transaction and revision numbers > > >On Mon, Sep 6, 2010 at 7:29 PM, Giulio Troccoli < > giulio.trocc...@uk.linedata.com> wrote: > > >Is there a special format of a transaction number? > >I would like to write a method in perl that gets a number, > either transaction or revision, and then adds the correct --revision or > --transaction parameter (for the svnlook command). So if there is a special > format for a transaction number I can use a regular expression to check it. > > > >The difference between a transaction and revision number depends > purely on context. AFAIK, the only time a transaction number is available is > within a pre-commit hook - once the transaction has been committed, it's a > revision number. > >What context would your script be run in? > >Cheers, >Daniel B. > > > The class will be used by both the pre- and post-commit hooks, hence the > need to distinguish between transaction or revision. And I would like to do > it by just looking at the transaction/revision number. > I think transactions are in the format of 999-9 (where 9 is any single > number) while revisions are in the format 9. If that's true, then I can > check for the dash and I'm done. Can anyone confirm it to me? Again, I think you would be better using it based on context, rather than the actual string format (this could change down the track). Something like this would be the simplest (but not the best): PerformAction(repository_uuid, transaction_Id, revision_Id) - for pre-commit hook, only populate the first two parameters - for post-commit hook, populate the first and third parameters Cheers, Daniel B.
Re: Wrong value in db/format when creating from TortoiseSVN
On Tue, Sep 28, 2010 at 5:23 AM, Tech Geek wrote: > I have the subversion server running on a Debian Linux machine. The > repositories are residing on a Windows domain shared network drive on the > network which is mapped on the Linux machine as: > mount -t cifs //software/svn_repositories /var/lib/svn/ -o > username=mynet/techgeek,password=**,uid=www-data,gid=subversion,iocharset=utf8 > > All the developers/users access the repositories using TortoiseSVN client > from Windows machine. > > The problem is that if the repositories were created from TortoiseSVN then > upon accessing the repositories (For example http://svnserver/svnrepos) I > get: > human-readable errcode="160043": Could not open the requested SVN > filesystem > > However, if I create new repositories from the Linux machine (on which > subversion is running), then everything works fine. > > I noticed when creating repositories from TortoiseSVN the value in > db/format is "4" (non-working) and while creating repositories from Linux > the value is "3" (working). > This indicates that the version of SVN on the linux box, and the version of TSVN are not the same. I don't know what the repository version numbers are that correspond to each svn/TSVN version (and you didn't mention which versions you have installed). Either downgrade TSVN, or upgrade SVN on the linux machine (upgrading the linux machine is probably easiest). > If I change the vaule from "4" to "3" for the repositories that were > created by TortoiseSVN then I do not longer get the above error message. > Never manually modify anything under the repository/db directory. > Sounds like there is some incompatibility between the subversion engine (on > linux) and the TortoirseSVN. > > I would like to enable developers/users to create repositories using > TortoiseSVN client. Do I have to live with this situation or is there a more > elegant workaround rather than changing the value of db/format file manually > everytime a new repository is created? > Cheers, Daniel B.
Re: Wrong value in db/format when creating from TortoiseSVN
On Tue, Sep 28, 2010 at 10:49 AM, Tech Geek wrote: > >I don't know what the repository version numbers are that correspond to > each svn/TSVN version (and you didn't mention which >versions you have > installed). > Linux SVN Server version 1.5.1 (r32289) > TSVN - 1.6.10 (32-bit) > That looks like a problem. TSVN is creating a repository in a format the the Linux SVN does not understand. Try upgrading the Linux version. Cheers, Daniel B.
Re: SVN branching and merging
On Thu, Sep 30, 2010 at 6:14 AM, Nigel Benns wrote: > I have a question about SVN merge. > I would like to know if it is possible to do this with merging. > > I would like a "trunk" to hold config files for an application. > Then I would like 3 branches, dev, test and uat. > > I want the trunk branch to contain either no addresses or place holders for > addresses and the branches to hold the addresses for their respective > environments. > > I want to make all of the changes to the trunk, and then have the changes > get copied to each of the branches and not have the branch specific > information get removed. > > Or something along these lines anyway > Is anything like this possible with SVN? > > Sure, we do a similar thing: r2 -> copy trunk to branches/dev r3 -> modify configuration in branches/dev Unless a change is made to that line in /trunk, the change won't get removed during a merge. Will you be merging between branches? Ie, merge branches/dev to branches/test? Cheers, Daniel B.
Re: Subversion 1.6.13 Released
On Sat, Oct 2, 2010 at 10:36 PM, Sjoerd Kivits < sjo...@separator-spareparts.de> wrote: > > Hi, > > Is it possible to download windows binaries for subversion server > somewhere? > I could only find packages including apache and so on... > > Brg, > > Sjoerd > I get mine from SlikSVN (http://www.sliksvn.com/en/home/). They might take a little while until the new installer is put up. Cheers, Daniel B. -Oorspronkelijk bericht- > Van: hy...@hyrumwright.org namens Hyrum Wright > Verzonden: vr 1-10-2010 19:12 > Aan: announce > Onderwerp: Subversion 1.6.13 Released > > > I'm happy to announce Subversion 1.6.13, available from: > > http://subversion.tigris.org/downloads/subversion-1.6.13.tar.bz2 > http://subversion.tigris.org/downloads/subversion-1.6.13.tar.gz > http://subversion.tigris.org/downloads/subversion-1.6.13.zip > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.bz2 > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.gz > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.zip > > This is a bugfix release, part of the 1.6.x release series. Of note, this > release includes a fix which addresses CVE-2010-3315, a security issue when > using 'SVNPathAuthz short_circuit'. More information can be found here: > http://subversion.apache.org/security/CVE-2010-3315-advisory.txt > > The MD5 checksums are: > > 7ae1c827689f21cf975804005be30aeb subversion-1.6.13.tar.bz2 > 8451f5d771edc0a0302bd9a52d54e150 subversion-1.6.13.tar.gz > dd4009b239a5354b434e5f66cddde145 subversion-1.6.13.zip > 2a7d662bac872c61a5e11c89263d7f07 subversion-deps-1.6.13.tar.bz2 > 688bdb107731f9db2f3b6297b663a68d subversion-deps-1.6.13.tar.gz > bb960d37f835e5e556e23e4eb85a9b08 subversion-deps-1.6.13.zip > > The SHA1 checksums are: > > 185efd129c3c4b04f1544d62bb9a3fcd0f58ba29 subversion-1.6.13.tar.bz2 > 06d3afc49182c80ea712c13409c008d27a4e889b subversion-1.6.13.tar.gz > 6530528fae0335cd8495ebf1f2072e2dd9df2e31 subversion-1.6.13.zip > e51bffda416a3a9abe068aab6f90d174dedef352 > subversion-deps-1.6.13.tar.bz2 > 1faa5ba0c87210f534ed445d061e4955396524d4 subversion-deps-1.6.13.tar.gz > 945ef9f68998aedf320af50d220e47a470684a06 subversion-deps-1.6.13.zip > > PGP Signatures are available at: > > http://subversion.tigris.org/downloads/subversion-1.6.13.tar.bz2.asc > http://subversion.tigris.org/downloads/subversion-1.6.13.tar.gz.asc > http://subversion.tigris.org/downloads/subversion-1.6.13.zip.asc > > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.bz2.asc > > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.tar.gz.asc > http://subversion.tigris.org/downloads/subversion-deps-1.6.13.zip.asc > > For this release, the following people have provided PGP signatures: > >Senthil Kumaran S [1024D/6CCD4038] with fingerprint: > 8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038 >Philip Martin [2048R/ED1A599C] with fingerprint: > A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C >Paul T. Burba [1024D/53FCDC55] with fingerprint: > E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 >Julian Foad [1024D/353E25BC] with fingerprint: > 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC >Bert Huijben [1024D/9821F7B2] with fingerprint: > 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 >Hyrum K. Wright [1024D/4E24517C] with fingerprint: > 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C >Stefan Sperling [1024D/F59D25F0] with fingerprint: > B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 >Mark Phippard [1024D/035A96A9] with fingerprint: > D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 > > Release notes for the 1.6.x release series may be found at: > > http://subversion.apache.org/docs/release-notes/1.6.html > > You can find the list of changes between 1.6.13 and earlier versions at: > > http://svn.apache.org/repos/asf/subversion/tags/1.6.13/CHANGES > > Questions, comments, and bug reports to us...@subversion.apache.org. > > Thanks, > - The Subversion Team > > >
Re: fsfs storage
On Mon, May 11, 2015 at 10:56 AM NS Klanten wrote: > Hello all, > > Where are the "initial" or base text files (source codes) are stored in > fsfs storage ? > > I commit a new source code to my svn server, however after searching all > the related svn folders in my server, I can not find the plain text file. I > assume that source code is just stored as plain text in fsfs storage and it > isn't hashed, is my assumption correct? > The SVN repository should be treated like a black box. You checkout code, you commit code, but as far as where that actual data is stored, it shouldn't be messed with directly. There are numerous SVN clients available for interacting with the repository. What are you trying to achieve?
Re: Feature request: Save the old file when svn revert
On Thu, Jul 23, 2015 at 7:16 PM Grierson, David wrote: > > -Original Message- > > From: Branko Čibej [mailto:br...@wandisco.com] > > Sent: 23 July 2015 07:59 > > To: users@subversion.apache.org > > Subject: Re: Feature request: Save the old file when svn revert > > > > On 22.07.2015 15:51, Bert Huijben wrote: > > > > > >> -Original Message- > > >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > >> Sent: woensdag 22 juli 2015 13:43 > > >> To: Markus Schaber > > >> Cc: Grierson, David ; > d...@subversion.apache.org; > > 牛 > > What we really want here is "svn stash", i.e., an equivalent to "git > > stash". In other words, I would not consider changing how "svn revert" > > works; instead, I'd like to design a new working copy feature that does > > more useful stuff than just saving away local modifications on revert. > > Since any such saving would require a working copy format change to be > > even remotely useful, we may as well consider introducing whole-hawg > > working copy state management. > > Guys, > > I think you're needlessly over-complicating things. > > Genuinely - what's wrong with just saving the modified item to a new name > (e.g. $item.reverted)? > > Okay - you /might/ end up with files "cluttering up" a working copy ... so > you remove them if they're troubling you. They won't have been created > unless you explicitly opted-in to have the revert save the modifications. > If you actually wanted to keep them then they're not going to trouble you > If users have to opt-in, and remember to have these modifications saved, they're going to forget, and the data will be lost anyway. I would recommend doing copy foo foo.bak & svn revert foo or svn diff . > ..\diff.patch & svn revert -R . Both scenarios saves a copy of the changes, and then revert, without a coding change. Cheers, Daniel B.
1.9 - Can't resolve to 'mine full' option for binary file conflict
Hi guys, I've just upgraded to SVN 1.9. One of the first things I noticed is that when a binary file conflict is raised during an SVN update, I can no longer use the 'mine-full' option to resolve. The only options I have are: (r) working and (tf) theirs-full. I can't use the 'r' (working) option, as I get a message of "Invalid option; use diff/edit/merge/launch before choosing 'mark resolved'. If I postpone, and try resolving afterwards, I get the following errors; > svn resolve file.binary --accept mine-full svn: warning: W155027: Conflict on 'file.binary' could not be resolved because the chosen version of the file is not available. svn: E155027: Failure occurred resolving one or more conflicts I can't find anything in the release notes about the removal of the 'mine-full' option on binary files. Was it intentional? If so, what's the intended workflow for resolution? Current version: svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0) compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200 Cheers, Daniel B.
Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict
Thanks, Bert. I understand the removal of "mine-full", and combining it with the "working" option. But, the issue is that there is no functional option that allows the user to select to keep the "working" (mine) version of the conflict. If I select (r) (accept the working version of the file), I get a validation error: "Invalid option; use diff/edit/merge/launch before choosing 'mark resolved". The remaining three options (theirs-full, postpone and postpone all) either result in the conflict remaining, or data loss by removing the working file altogether. On Mon, Sep 14, 2015 at 8:04 PM Bert Huijben wrote: > > > > -Original Message- > > From: Stefan Hett [mailto:ste...@egosoft.com] > > Sent: maandag 14 september 2015 09:54 > > To: users@subversion.apache.org > > Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file > conflict > > > > On 9/14/2015 7:56 AM, Daniel Becroft wrote: > > > Hi guys, > > > > > > > > > I've just upgraded to SVN 1.9. One of the first things I noticed is > > > that when a binary file conflict is raised during an SVN update, I can > > > no longer use the 'mine-full' option to resolve. > > > > > > The only options I have are: (r) working and (tf) theirs-full. > > > > > > I can't use the 'r' (working) option, as I get a message of "Invalid > > > option; use diff/edit/merge/launch before choosing 'mark resolved'. > > > > > > If I postpone, and try resolving afterwards, I get the following > errors; > > > > svn resolve file.binary --accept mine-full > > > svn: warning: W155027: Conflict on 'file.binary' could not be resolved > > > because the chosen version of the file is not available. > > > svn: E155027: Failure occurred resolving one or more conflicts > > > > > > I can't find anything in the release notes about the removal of the > > > 'mine-full' option on binary files. Was it intentional? If so, what's > > > the intended workflow for resolution? > > > > > > Current version: > > > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0) > > >compiled Aug 26 2015, 17:09:55 on > x86/x86_64-microsoft-windows6.2.9200 > > > > > > Cheers, > > > Daniel B. > > Hi Daniel, > > > > just to second ur observation: > > I think I ran into the same problem last Thursday/Friday using TSVN > > 1.9.1. I didn't report it yet because I didn't check out whether it's a > > TSVN or an SVN issue. > > Using TSVN, it however also gives me the "file not found" error when I > > try to resolve a binary conflict selecting "Use Repository version" > > during the merge dialog. > > > > I'm sure u are already ware, but just in case: My workaround was to let > > the file in conflict and afterwards resolve the conflict by reverting > > the file (so it was in the repository's state which I intended). > > In case of a binary file the original working copy version is left as the > working version, whereas for text conflict the working copy version is > changed into a mine version and a best effort merge is performed to the a > new working copy version potentially containing conflict markers. > > In this case you probably get the result you want by just choosing the > working copy version. The Subversion developer responsible for choosing > this UI determined that it didn't make much sense to offer two different > resolve options with exactly the same result. > > Bert > > > > > -- > > Regards, > > Stefan Hett > > >
Relative URLs on command line
Hi, I'm trying to use the relative URL syntax from the command line, as mentioned in a 2009 blog post[1]. However, I'm having troubles getting it to work. >From inside a working copy for /branches/release: > svn switch ^/trunk svn: E125002: '/trunk' does not appear to be a URL > svn merge -c 1 ^/trunk . svn: E155007: 'C:\trunk' is not a working copy Everything works fine when using the full URLs, but I expected the relative paths to work. Environment: Windows 10 64-bit, version 1.9.5-SlikSvn (SlikSvn/1.9.5) Is this a *nix-only feature? Cheers, Daniel B.
svn log - combining 'search' and 'limit'
Hi, I've come across something which seems to be working not as expected, but I'm not sure it is a bug. At the moment, I can do `svn log --search "Foo"` to get all the log messages containing "Foo", and `svn log --limit 10` to get the last 10 log messages. I expected that if I combined these (for example, `svn log --search "Foo" --limit 10`), that I would get the last 10 log messages that contained the search criteria, however it only showed those log messages in the last 10 that contained "Foo". If the latest log message that contained "Foo" was number 11, nothing would be displayed. Real-world example, using: >svn log https://svn.apache.org/repos/asf/subversion/trunk --search "SEGV" --limit 1 I would expect to see r1798157, however I don't see anything (as the revision returned from --limit 1 is not it). Cheers, Daniel B.
Re: svn vs. git
We did a similar comparison as well, and again stuck with SVN. However, this was predominantly due to the challenge of getting devs to relearn a whole new process (we had enough trouble migrating from lock-modify-unlock to a checkout/modify/commit workflow). We did like the off-line process, and the ability to stash/unstash changes, and the speed performance was immense. The biggest advantage that we saw git giving us is integration with third party apps out of the box. The number of vendors who have added git integration into their apps far outpace the SVN integration, and it makes it hard to stick with SVN when we can't take full advantage of these systems. Code review is the main one, but this is driven by github.com more than git itself, I guess. I'm not sure what changes something like SVN 2.0 would bring, given that the entirety of git's lifetime is wholly contained with SVN 1.x's, but it will be interesting. I'm sure the devs are looking/investigating that. On Fri., 21 Jul. 2017, 08:01 Scott Aron Bloom, wrote: > > > > > *From:* Nathan Hartman [mailto:hartman.nat...@gmail.com] > *Sent:* Thursday, July 20, 2017 14:39 > *To:* Subversion > *Subject:* Re: svn vs. git > > > > On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn > wrote: > > Not wanting to start a flame war, but for all svn users and admins out > there that sometimes need to have this conversation ... I found this to be > a very nice website: > > > > https://svnvsgit.com > > > > (I'm not affiliated with the website, just ran into it) > > > > Thank you! Thank you! Thank you! > > > > I did recently have this conversation and this website could have helped > significantly. > > > > There seem to be some comparisons out there that are comparing DVCSs > against ancient versions of Subversion. Probably those comparisons are old > and therefore their argument may have been valid at the time. But if those > comparisons are more recent, then there's a problem. Either the person > making the comparison is honestly unaware of progress made in Subversion's > development over the years, or they are deliberately comparing to old > versions to make Subversion look bad. > > > > Regardless of how or why, I think the perception out there is just plain > wrong. I think Subversion is due a lot more credit than it gets. As I > mentioned in another thread (which may have prompted this one), we recently > evaluated other systems. We did not do this out of desire to migrate away > from Subversion; rather we did it in order to understand what's happening > in our industry, and as such we wanted to answer the question: will > switching to something else give us some new advantage? We gave git and > others a fair chance, and based on various technical, usability, and > management criteria we reached the conclusion that Subversion has been and > still is the best system for us. We manage all sorts of data with it, not > just program code. > > > > While I'm here, I'll comment on a couple of significant issues mentioned > at that site. > > > > Item #7 mentions the issue of a single monolithic repository vs numerous > smaller repositories, and the atomic whole-project commit, consistent > branches, and large-scale rafactoring made possible by it. These are > extremely important to us. We have numerous components whose history and > state must remain matched as they evolve. With the monolithic repository, > this happens by definition. Losing that by breaking things up into multiple > repositories (to avoid cloning a gigantic monolithic repo for every working > copy) would push a maintenance burden to everyone on our team, which is > unacceptable from a management perspective. > > > > Item #11 mentions the issue of immutable history. We know from experience > that the ability to reproduce the exact bits at a point in time is crucial > to us. With Subversion, this very significant requirement is fulfilled, and > tremendous problems we had in our pre-Subversion days have disappeared. > Losing immutable history would be a huge step backwards for us. > > > > One myth that is not mentioned on that page is the famous, "But you can't > work offline!" Being able to work "offline" is supposed to be the biggest > selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First > of all, there is nothing inherent to Subversion that "prevents" you from > working offline. You can work, you just can't do server side operations. Is > that such a big deal? And if it is, do you mean to tell me that in this day > and age of cloud services and IoT, where every single thing you do requires > Internet access, that you're ever really "offline" for long enough that it > matters? And even if you are planning to spend a year alone on a deserted > island, nothing stops you from doing "svnadmin create" on your local > computer and making as many commits as you want. But that doesn't make > sense, because the longer you work in isolation, the less likely it is that > your work will mer
SlikSVN no longer active?
Hi, Is SlikSVN still being maintained? The latest compiled build available on the website is 1.9.7 (current version is 1.11.x, with 1.12.x on the way). If it's no longer being maintained, it would be good to remove it from the list of valid binaries: https://subversion.apache.org/packages.html#windows Thanks. --- Daniel Becroft
svn merge --record-only reports extraneous paths
Hi, When running an 'svn merge -c', I get a particular set of paths updated with svn:mergeinfo. Fine, no issues with this. However, when running an 'svn merge -c --record-only', I get a far greater set of paths *reported* as updated, but they actually aren't. The paths that are report actually do have their own 'svn:mergeinfo' properties, but they don't get changes by the merge command (which I expected). I think the paths either need to be updated, or not displays. Using: svn 1.7.7 --- Daniel Becroft
svn checkout --set-depth ignores externals
Hi, In the root of our trunk, we have a 'build_tools' folder which is defined as an external. For example /trunk /build_tools (external) /alpha /A /beta /gamma build.xml build.properties If we checkout using 'svn checkout --depth immediates', this folder is ignored, but I continue to get alpha/beta/gamma folders (empty). I can't seem to get it back without checking out the entirety of trunk. Any ideas? Is this intended behaviour? --- Daniel Becroft
Re: svn checkout --set-depth ignores externals
On Thu, Jul 3, 2014 at 4:01 PM, Daniel Becroft wrote: > Hi, > > In the root of our trunk, we have a 'build_tools' folder which is defined > as an external. > > For example > /trunk > /build_tools (external) > /alpha > /A > /beta > /gamma > build.xml > build.properties > > If we checkout using 'svn checkout --depth immediates', this folder is > ignored, but I continue to get alpha/beta/gamma folders (empty). I can't > seem to get it back without checking out the entirety of trunk. > > Any ideas? Is this intended behaviour? > Sorry, using 1.8.8 (r1568071).
Merged revisions missing when using 'svn log -g'
Hi, svn 1.8.8 (r1568071) I've found an interesting scenario where merged revisions are not appearing in the output of an 'svn log -g' command. The revision is included in the svn:mergeinfo changes for the merged revision, but does not appear in the log output. The file changes are in that commit The property change includes: svn diff -c 25041 --depth empty Index: . === --- . (revision 25040) +++ . (revision 25041) Property changes on: . ___ Modified: svn:mergeinfo Merged /trunk:r24741-24742,24755,24764,24770-24771,24776,24790,24859,24873,24 885-24886,24889,24896,24898,24900-24902,24910-24911,24914,24918,24921,24925,2492 9,24936,24938,24940-24942,24944,24946-24947,24957,24961-24962,24965,24967,24969, 24971-24972,24974-24976,24979-24987,24990-24991,24995-24997,25002-25003,25011-25 012,25015-25017,25019-25020,25022-25023,25025,25027,25030-25031,25033-25035 But the 'svn log -g' output for that revision gives the follow revisions as the 'latest' revisions merged. Notice that 25030-31 does not appear, nor does 25025 (even though the changes for these revisions are in the commit, and they were on /trunk). r25041 r25027 r25023 r25017 r25016 r25003 Any ideas on what else I need to look at? Or any other information that I need to provide. Cheers, Daniel B.
Tree conflict resolution options on command-line
Hi, Using: svn 1.8.8 (r1568071) When attempting to merge a change into my working copy, I am getting a tree conflict (change adds a file, file already exists). No problem with the conflict. Conflict discovered when trying to add 'foo\A\B\c.p'. An object of the same name already exists. Select: (mf) my version, (tf) their version, (p) postpone, (q) quit resolution, (h) help: If I select to use either of 'mf' or 'tf', I get: Summary of conflits: Tree conflicts: 0 remainings (and 1 already resolved) svn: E155027: Tree conflict can only be resolved to 'working' state; 'foo\A\B\c.p' not resolved. My question is: If a tree conflict can only ever be resolved to 'working', then (a) why isn't 'working' an option in the resolution prompt?; and (b) why am I being asked to choose something that isn't applicable anyway? --- Daniel Becroft
svn status & external definitions
Hi, On a fresh checkout from a repository, an 'svn status' will return the following: X alpha X beta\B X beta\C These are the folders created by svn:externals properties. No problem here. However, using an 'svn status --ignore-externals' command does not change the output - the external folders continue to be listed. The help text for this switch just says '--ignore-externals : ignore externals definitions'. Is this intended behaviour? If so, is what scenario will this switch do something? Using: svn 1.8.8 --- Daniel Becroft
Re: svn status & external definitions
On Mon, Dec 8, 2014 at 5:07 AM, Branko Čibej wrote: > On 06.12.2014 14:59, Bert Huijben wrote: > > > >> -Original Message- > >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > >> Sent: zaterdag 6 december 2014 12:28 > >> To: Daniel Becroft > >> Cc: subversion > >> Subject: Re: svn status & external definitions > >> > >> Daniel Becroft wrote on Tue, Dec 02, 2014 at 14:44:06 +1000: > >>> Hi, > >>> > >>> On a fresh checkout from a repository, an 'svn status' will return the > >>> following: > >>> > >>> X alpha > >>> X beta\B > >>> X beta\C > >>> > >>> These are the folders created by svn:externals properties. No problem > > here. > >>> However, using an 'svn status --ignore-externals' command does not > > change > >>> the output - the external folders continue to be listed. > >>> > >>> The help text for this switch just says '--ignore-externals : ignore > >>> externals definitions'. > >>> > >>> Is this intended behaviour? > >> Not sure.. > > Are we looking at a file external or at a directory external? > > Doesnt' matter. The status tells you that alpha, beta/B and beta/C are > roots of external working copies. This information is pertinent to the > top-level working copy, not the contents of the external WCs. So, status > is not descending into the external trees; it's effectively just > reporting the contents of svn:externals properties defined in your > top-level working copy. > > This becomes clearer in the case where the external tree is actually in > a state where status would have something to report. For example, using > a test setup with an external directory and a locally added file inside it: > > $ svn proplist --verbose > Properties on '.': > svn:externals > ^/top/a ext > > By default, "svn status" will descend into the external tree: > > $ svn status > X ext > > Performing status on external item at 'ext': > A ext/c/foo > > With the added option, it won't: > > $ svn status --ignore-externals > X ext > > But it will report the external definition in the top-level working copy. > Okay, this all makes sense. I guess it was strange that, from my perspective, whether something is an external or not would also have been included when ignoring externals. If there are 10 externals, and one modified file, it is difficult to see the modification without manually looking through each one. Cheers, Daniel B.
