Re: script or tool to walk back thru 1 file's history diffing..
On Fri, Sep 9, 2011 at 2:06 AM, wrote: > Would like to write a script to follow the history of a single > file, backwards, diffing the file w/it's prior version all the way > back to the 1st version. > > By using 'svn info' to get the last chgd rev, and running 'svn > diff -c $lastchgd_rev ...', this seems simple enough if the URL to > the file does not change; but if the pathname in svn to the file > is renamed there is no choice but to look at 'svn log', right? > > -- > thanks/regards, > Tom > > -- > Does such a command line tool already exist? Well, yes, such a command line tool already exists :-). At least, it does in 1.7.0 RC2: 'svn log --diff' will produce the log with the diffs inline. Take a look at one of the 1.7.0 pre-release binaries available here: http://subversion.apache.org/packages.html#pre-release -- Johan
Re: Anyone able to produce Solaris binaries of 1.7.0-rc2 ?
On Thu, Sep 8, 2011 at 2:13 PM, Mark Phippard wrote: > On Thu, Sep 8, 2011 at 7:31 AM, Johan Corveleyn wrote: >> On Mon, Sep 5, 2011 at 4:30 PM, Mark Phippard wrote: >>> On Mon, Sep 5, 2011 at 8:51 AM, Johan Corveleyn wrote: Is there anyone on this list able to produce binaries of 1.7.0-rc2 client for Solaris? I know both Collabnet and Wandisco produce Solaris binaries, but they haven't (yet) built the 1.7 pre-releases for this platform. If either of them could fire up their build infrastructure for this, that would be great of course :-). Or anyone else ...? I'm mostly interested in x86 binaries right now, but also sparc binaries would be useful (to compare between two of our systems). >>> >>> There is a Solaris x86 client here: >>> >>> https://ctf.open.collab.net/sf/frs/do/listReleases/projects.csvn/frs.svn_release_candidates >>> >>> Also, Windows 32/64 and Linux 32/64. Only thing we do not have >>> available yet is Solaris sparc. >> >> It took me a while but I finally took this package for a spin today. >> Unfortunately, there seems to be something corrupt with the package: >> >> bash-3.00# pkgadd -d CSVNclnt-1.7.0.1-x86-local >> pkgadd: ERROR: attempt to process datastream failed >> - bad format in datastream table-of-contents >> pkgadd: ERROR: could not process datastream from >> >> >> Can you verify? Has anyone else tried this package (1.7.0-rc2 for Solaris >> x86)? > > I just downloaded and successfully installed the version I posted. I > did it from the same site just to be sure it had not become corrupted > in posting it. > > Did you use gzip -d to decompress it first? Strange. We tried several things, and still get that same error. - We downloaded it again. - Tried several ways of copying it to the target server (WinSCP and such) - It gunzips correctly, there seems to be no problem there - We also tried to extract it on Windows (Winzip or 7zip, not sure), before copying the package to the server. Maybe there is some strange platform difference, or difference in the packaging system ... 'uname -a' reports: SunOS testhost 5.10 Generic_144489-17 i86pc i386 i86pc It's actually a virtual machine running on an ESX cluster, but I don't think that matters. OTOH, the release package of 1.6.17 client from CollabNet did install successfully on this machine. Is there anything special we need to do? Maybe I could verify sha1 checksums of both the .gz archive and the package after decompression, if you can provide those, to check that nothing went wrong in transit? Thanks, -- Johan
Re: script or tool to walk back thru 1 file's history diffing..
On Fri, Sep 09, 2011 at 09:44:06AM +0200, Johan Corveleyn wrote: > On Fri, Sep 9, 2011 at 2:06 AM, wrote: > > Would like to write a script to follow the history of a single > > file, backwards, diffing the file w/it's prior version all the way > > back to the 1st version. > > > > By using 'svn info' to get the last chgd rev, and running 'svn > > diff -c $lastchgd_rev ...', this seems simple enough if the URL to > > the file does not change; but if the pathname in svn to the file > > is renamed there is no choice but to look at 'svn log', right? > > > > -- > > thanks/regards, > > Tom > > > > -- > > Does such a command line tool already exist? > > Well, yes, such a command line tool already exists :-). At least, it > does in 1.7.0 RC2: > > 'svn log --diff' will produce the log with the diffs inline. > > Take a look at one of the 1.7.0 pre-release binaries available here: > http://subversion.apache.org/packages.html#pre-release If you use log --diff in some automated process, be aware that some diff options (among them --show-copies-as-adds and --no-diff-deleted) are hard-coded and cannot be changed. There is (at least) one diff bug which can cause surprises. An automated process consuming log --diff output should be aware of it. If you ask for the diff of one newly added file, you can end up getting a diff for an entire subtree, or even the entire tree in the repository at the given revision. See http://subversion.tigris.org/issues/show_bug.cgi?id=2873#desc7 The intended use case for log --diff is code review by a human.
Re: Searching in SVN
On Friday 09 September 2011 12:04 PM, Waseem Shahzad wrote: Hi guys! I would like to search a file amongst 1000+ files within a Folder. Is there any way to do this with smart way. svn ls -R | grep Regards Prabhu
RE: Searching in SVN
Thanks What we want to same in Tortoise SVN? Muchas Gracias, Waseem Bukhari CM - Ext: 331 From: Prabhu Gnana Sundar [mailto:prabh...@collab.net] Sent: Friday, September 09, 2011 7:09 AM To: users@subversion.apache.org Subject: Re: Searching in SVN On Friday 09 September 2011 12:04 PM, Waseem Shahzad wrote: Hi guys! I would like to search a file amongst 1000+ files within a Folder. Is there any way to do this with smart way. svn ls -R | grep Regards Prabhu
Re: How to migrate just part of a repo to another server
On Thu, Sep 8, 2011 at 4:13 AM, Markus Schaber wrote: > Hi, Les, > > Von: Les Mikesell [mailto:lesmikes...@gmail.com] >> >> 2011/9/7 Thorsten Schöning : >> > >> >> Would it work to start the dump at the revision of the move to the >> >> current path (without --incremental) if I'm willing to lose the older >> >> history that might have been in a cvs conversion? >> > >> > Is space a problem or why do you not just dump and load the whole >> > repository and delete every path you don't need using svn? It may be >> > the fastest solution and really preserves all history. >> >> There are currently a large number of projects in one repository. The size >> is still manageable but approaching being awkward to back up and >> manipulate. The point of splitting would be make the size for each >> project reasonable - or perhaps to split out a project to be managed by a >> group that should not have access to some of the other parts. >> From the docs I would have expected giving a starting revision to svnadmin >> dump to eliminate the history - and need for paths containing it - before >> the specified point. Is that not the case? > > I did not follow the thread, but did you have a look at svndumpfilter? > http://svnbook.red-bean.com/en/1.6/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering > > Best regards > > Markus Schaber svndumpfilter is very awkward if components have been "copied" or "moved" from one project to another, or if revisions exist that manipulate multiple projects. That's particularly common when a site policy change is made to list all .c files with svn:keywords, for example, and not done project by project. Frankly, I've given up on doing such complex migrations. There's a point where you lock down the old repository in read-only mode, do an svn export and svn import into a new repository, and start with a new repository with a new uuid and a revised layout. The commit message on the first revision can state where the old repository is, and if absolutely necessayr, the old repository can use svn:externals to point to the new one. But then it's *done*, and you have a chance to set aside years of unnecessary logs and actual binary commits into a separate repository and start *over*.
"svn revert --depth=files"
Hi, In a working copy, "svn delete" a directory which contains files. Then do "svn revert --depth=files path/to/directory". As far as I can remember, this did revert the directory as well as the deleted files in SVN 1.6. It only reverts the deleted directory in SVN 1.7, leaving the files marked as deleted. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: "svn revert --depth=files"
--depth=immediates properly reverts all children of the deleted directory. Markus Schaber wrote on Fri, Sep 09, 2011 at 14:06:21 +0200: > Hi, > > In a working copy, "svn delete" a directory which contains files. > > Then do "svn revert --depth=files path/to/directory". > > As far as I can remember, this did revert the directory as well as the > deleted files in SVN 1.6. > > It only reverts the deleted directory in SVN 1.7, leaving the files > marked as deleted. > > Best regards > > Markus Schaber > > ___ > We software Automation. > > 3S-Smart Software Solutions GmbH > Markus Schaber | Developer > Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | > Fax +49-831-54031-50 > > Email: m.scha...@3s-software.com | Web: http://www.3s-software.com > CoDeSys internet forum: http://forum.3s-software.com > Download CoDeSys sample projects: > http://www.3s-software.com/index.shtml?sample_projects > > Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | > Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 >
AW: "svn revert --depth=files"
Hi, Daniel, It even is more strange: If I do "svn revert --depth=files foo/bar foo", then only the directory foo is reverted, and the file bar is not restored. Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > --depth=immediates properly reverts all children of the deleted directory. But this also restores sibling directories to the file I want to restore, right? > Markus Schaber wrote on Fri, Sep 09, 2011 at 14:06:21 +0200: > > Hi, > > > > In a working copy, "svn delete" a directory which contains files. > > > > Then do "svn revert --depth=files path/to/directory". > > > > As far as I can remember, this did revert the directory as well as the > > deleted files in SVN 1.6. > > > > It only reverts the deleted directory in SVN 1.7, leaving the files > > marked as deleted. > > Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: "svn revert --depth=files"
Markus Schaber wrote on Fri, Sep 09, 2011 at 14:20:28 +0200: > Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > > > --depth=immediates properly reverts all children of the deleted > > directory. > > But this also restores sibling directories to the file I want to > restore, right? Of course; they are different things. I was merely pointing that only svn_depth_files but not svn_depth_immediates is broken.
AW: "svn revert --depth=files"
Hi, Von: Markus Schaber [mailto:m.scha...@3s-software.com] > It even is more strange: If I do "svn revert --depth=files foo/bar foo", > then only the directory foo is reverted, and the file bar is not restored. This also displays no warning that foo/bar is ignored. In addition, if I do "svn revert foo/bar", it silently does nothing. So to revert the file and the directory, I need to do "svn revert --depth=files foo foo/bar". AFAIR,This seems to be in contrast to the behavior of SVN 1.6 which brought an error message because bar was about to be reverted twice. This change in behavior breaks my CoDeSys integration - this is not a problem, I'm just fixing it in my code, but it may break other scripts and tools relying on the old behavior. Thanks, Markus > Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > > > --depth=immediates properly reverts all children of the deleted > directory. > > But this also restores sibling directories to the file I want to restore, > right? > > > Markus Schaber wrote on Fri, Sep 09, 2011 at 14:06:21 +0200: > > > Hi, > > > > > > In a working copy, "svn delete" a directory which contains files. > > > > > > Then do "svn revert --depth=files path/to/directory". > > > > > > As far as I can remember, this did revert the directory as well as > the > > > deleted files in SVN 1.6. > > > > > > It only reverts the deleted directory in SVN 1.7, leaving the files > > > marked as deleted. > > > Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: 1.7.0 upgrade doesn't properly follow svn:externals
On 09/08/2011 06:21 PM, Scott Palmer wrote:
> Just tried 1.7.0RC2 and noticed that bugs with svn upgrade are still present.
>
> If you have svn:externals in the top level of your working copy they seem to
> be converted, but if those external references also use svn:externals then
> those nested working copies are not upgraded.
>
> Is anyone else seeing this?
Hi Scott,
thanks for the report! I can reproduce the problem with attached test
script. (The script uses my local bin/svn paths of built Subversion
versions, so I also attached a screenshot output.)
I am "moving" this discussion to the dev@ list, please reply there.
Note that the test upgrades the external dir XB, but fails to upgrade the
nested external dir XB/XC:
[[[
...
Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.
...
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
]]]
And note that a .svn dir remains in XB/XC (seen in the final 'ls')
I'll see if I can find a solution.
~Neels
#!/usr/bin/env bash
## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
## export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
##built source tree. The next line is the only line you should
##need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { "$SVNDIR/subversion/svn/svn" "$@"; }
# function svnserve() { "$SVNDIR/subversion/svnserve/svnserve" "$@"; }
# function svnadmin() { "$SVNDIR/subversion/svnadmin/svnadmin" "$@"; }
set -e
svn --version
# current path points at Subversion 1.7.x. Change that to 1.6.x:
OLD_PATH="$PATH"
export PATH="$HOME/pat/1.6.17/prefix/bin:$OLD_PATH"
svn --version | grep version
BASE="$(mktemp -d "/tmp/$(basename "$0").XXX")"
echo "BASE = $BASE"
REPOS="$BASE/repos"
WC="$BASE/wc"
URL="file://$REPOS"
svnadmin create "$REPOS"
# enable all revprop changes
cat > "$REPOS/hooks/pre-revprop-change" < a
mkdir B
echo b > B/b
mkdir C
echo c > C/c
svn add a B C
svn ps svn:externals "^/C XC" B
svn ps svn:externals "^/B XB" .
svn ci -mm
svn up
# back to using Subversion 1.7.x
set +x
export PATH="$OLD_PATH"
set -x
svn --version | grep version
svn upgrade
ls -a XB/XC/
## END
set +x
echo "BASE = $BASE"
svn, version 1.7.0-dev (under development)
compiled Sep 7 2011, 21:15:48
Copyright (C) 2011 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/
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.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
BASE = /tmp/palmer.AtX
+ svn --version
+ grep version
svn, version 1.6.17 (r1128011)
Subversion is open source software, see http://subversion.apache.org/
+ svn co -q file:///tmp/palmer.AtX/repos /tmp/palmer.AtX/wc
+ cd /tmp/palmer.AtX/wc
+ echo a
+ mkdir B
+ echo b
+ mkdir C
+ echo c
+ svn add a B C
A a
A B
A B/b
A C
A C/c
+ svn ps svn:externals '^/C XC' B
property 'svn:externals' set on 'B'
+ svn ps svn:externals '^/B XB' .
property 'svn:externals' set on '.'
+ svn ci -mm
Sending.
Adding B
Adding B/b
Adding C
Adding C/c
Adding a
Transmitting file data ...
Committed revision 1.
+ svn up
Fetching external item into 'XB'
AXB/b
U XB
Fetching external item into 'XB/XC'
AXB/XC/c
Updated external to revision 1.
Updated to revision 1.
Fetching external item into 'B/XC'
AB/XC/c
Updated external to revision 1.
Updated to revision 1.
+ set +x
+ svn --version
+ grep version
svn, version 1.7.0-dev (under development)
Subversion is open source software, see http://subversion.apache.org/
+ svn upgrade
Upgraded '.'
Upgraded 'B'
Upgraded 'C'
Upgraded 'XB'
Upgraded 'B/XC'
+ ls -a XB/XC/
.
..
c
.svn
+ set +x
BASE = /tmp/palmer.AtX
signature.asc
Description: OpenPGP digital signature
cleaning up mergeinfo using svn 1.7
We have a repository that is seriously cluttered with the svn:mergeinfo property. I don't believe we ever used the buggy 1.5.x versions that added the property erroneously (although I could be wrong). However, due to a lax policy regarding where merges should occur, the property is now attached to files and directories all over the place. For example, when a user wants to double-commit his one-file change from release 1.3 to 1.2, he merges the change from the top-level of the 1.3 branch into the 1.2 branch and commits. The change in 1.2 appears as one text change and *137 property changes*! Note that one complication is the fact that some users have mistakenly committed only the file changes and the top-level directory prop change, but have left the rest of the property changes uncommitted. I was hoping that the improvements in this area that are coming in 1.7 would allow us to continue to use this polluted repository, because even though it would not clean up the mess, it would not continue to create merges that look much larger than they are (due to the numerous superfluous property changes). To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so I could experiment and see for myself. I did a simple merge from one branch to another. I was disappointed to see that the same miscellaneous group of files and directories below the top-level are having their snv:mergeinfo modified, even though they do not participate in the change. I guess I am not reading the documentation for 1.7 correctly, because I thought that this was one of the major changes; namely, that any object which is not affected by the merged changes would not have its svn:mergeinfo property changed. In my test, all files and directories that *currently* have svn:mergeinfo attached get the updated info from the merge being performed. This means that the backport of my one-file change looks like a much larger change. Here are my questions: 1. Assuming I don't clean up the repository, what help can I expect from 1.7 in terms of new merges? In other words, explain the behavior I should expect, given the state of my repository now and the test I performed above. 2. What other methods are recommended if 1.7 will not do what I'm hoping for? Are there any good cleanup scripts to help scrub the whole tree? (I tried mergeinfo-sanitize, to see what it was, but it did not allow me to authenticate??) 3. If I decide to simply prohibit users from making changes to svn:mergeinfo on any object besides the top-level directory itself, what are the unforeseen consequences that I need to worry about? For *this third question, *I'm not so concerned about information that might be lost during cleanup, although I know that is a huge issue. I'm more interested in the limitations this might place on us in the future, assuming we can clean up the tree completely so that *only* the top-level directory has svn:mergeinfo attached to it. For example, if a user commits two fixes using a single commit on 1.3, then wants to backport one of those fixes to 1.2, can the mergeinfo -- limited to only the top-level directory -- maintain all the information needed? Thanks, David
Re: cleaning up mergeinfo using svn 1.7
On Fri, Sep 09, 2011 at 12:17:15PM -0400, David Carson wrote: > To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so I > could experiment and see for myself. I did a simple merge from one branch > to another. I was disappointed to see that the same miscellaneous group of > files and directories below the top-level are having their snv:mergeinfo > modified, even though they do not participate in the change. I guess I am > not reading the documentation for 1.7 correctly, because I thought that this > was one of the major changes; namely, that any object which is not affected > by the merged changes would not have its svn:mergeinfo property changed. Did the change you were merging contain svn:mergeinfo property changes? If so, those will be applied to the working copy. If the revision rN you are merging from 1.2 into 1.3 was itself the result of a merge, and this merge was done with a 1.6 client, this would explain the problem.
test email message....
...this should be bounced, I can't seem to send to the list. I am sending this to get a bounce so I can forward it to IT. Sorry if this gets to the list, if it does, please ignore. BOb
RE: cleaning up mergeinfo using svn 1.7
> We have a repository that is seriously cluttered with the svn:mergeinfo > property. I don't believe we ever used the buggy 1.5.x versions that added > the property erroneously (although I could be wrong). However, due to a lax > policy regarding where merges should occur, the property is now attached to > files and directories all over the place. For example, when a user wants to > double-commit his one-file change from release 1.3 to 1.2, he merges the > change from the top-level of the 1.3 branch into the 1.2 branch and > commits. The change in 1.2 appears as one text change and 137 property > changes! > > Note that one complication is the fact that some users have mistakenly > committed only the file changes and the top-level directory prop change, but > have left the rest of the property changes uncommitted. It is possible that if you committed those property changes the mergeinfo would be elided. You may want to run a record-only merge, this should elide and extra mergeinfo that is on the child nodes. Afaik. BOb > > I was hoping that the improvements in this area that are coming in 1.7 would > allow us to continue to use this polluted repository, because even though it > would not clean up the mess, it would not continue to create merges that > look much larger than they are (due to the numerous superfluous property > changes). > > To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so I > could > experiment and see for myself. I did a simple merge from one branch to > another. I was disappointed to see that the same miscellaneous group of > files and directories below the top-level are having their snv:mergeinfo > modified, even though they do not participate in the change. I guess I am > not reading the documentation for 1.7 correctly, because I thought that this > was one of the major changes; namely, that any object which is not affected > by the merged changes would not have its svn:mergeinfo property > changed. > > In my test, all files and directories that currently have svn:mergeinfo > attached get the updated info from the merge being performed. This means > that the backport of my one-file change looks like a much larger change. > > Here are my questions: > 1. Assuming I don't clean up the repository, what help can I expect from 1.7 > in terms of new merges? In other words, explain the behavior I should > expect, given the state of my repository now and the test I performed > above. > 2. What other methods are recommended if 1.7 will not do what I'm hoping > for? Are there any good cleanup scripts to help scrub the whole tree? (I > tried mergeinfo-sanitize, to see what it was, but it did not allow me to > authenticate??) 3. If I decide to simply prohibit users from making changes to > svn:mergeinfo on any object besides the top-level directory itself, what are > the unforeseen consequences that I need to worry about? For this third > question, I'm not so concerned about information that might be lost during > cleanup, although I know that is a huge issue. I'm more interested in the > limitations this might place on us in the future, assuming we can clean up the > tree completely so that only the top-level directory has svn:mergeinfo > attached to it. For example, if a user commits two fixes using a single > commit > on 1.3, then wants to backport one of those fixes to 1.2, can the mergeinfo -- > limited to only the top-level directory -- maintain all the information > needed? > > Thanks, > David
Re: cleaning up mergeinfo using svn 1.7
On Fri, Sep 9, 2011 at 12:38 PM, Stefan Sperling wrote: > On Fri, Sep 09, 2011 at 12:17:15PM -0400, David Carson wrote: > > To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so > I > > could experiment and see for myself. I did a simple merge from one > branch > > to another. I was disappointed to see that the same miscellaneous group > of > > files and directories below the top-level are having their snv:mergeinfo > > modified, even though they do not participate in the change. I guess I > am > > not reading the documentation for 1.7 correctly, because I thought that > this > > was one of the major changes; namely, that any object which is not > affected > > by the merged changes would not have its svn:mergeinfo property changed. > > Did the change you were merging contain svn:mergeinfo property changes? > If so, those will be applied to the working copy. > > If the revision rN you are merging from 1.2 into 1.3 was itself the > result of a merge, and this merge was done with a 1.6 client, > this would explain the problem. > Bingo -- that makes sense. In my test, I updated a child branch with new parent content and that range of revisions contained one that was itself a merge which was performed using svn 1.6 (i.e., before taking the snapshot of the repository). OK, so let's try again. I've merged a change from another branch, which is a commit with a single file changed. The result is much better, but let me verify that I understand my results: - file a/b/c/foo.c shows the file changes -- OK - file a/b/c/foo.c also contains svn:mergeinfo changes -- I assume this is because it happens to be one of the many files that got contaminated with the property prior to this test. So, since it is part of the changeset for my merge, the prop has to be updated too. - directory (call it TLD/) contains svn:mergeinfo changes -- OK - TLD/a also contains svn:mergeinfo changes -- Same as above. Directory TLD/a is one of the directories which was previously contaminated, and since this path is 'involved' in the change, the prop has to be updated. I wouldn't say the path really involved, except that it is the path on wich foo.c sits. After all, TLD/a/ is not itself changed. Nonetheless, I can live with this. Now, are there any tools to aid in cleanup of the mess? Besides the large number of files/dirs with the prop attached, the prop itself has a large number of paths to contend with.
Re: problems with propset svn:ignore
Please keep idscussion on the mailing list by using Reply All. My reply below: On Sep 9, 2011, at 08:17, Randy Paries wrote: > On Thu, Sep 8, 2011 at 10:46 PM, Ryan Schmidt wrote: >> >> >> svn:ignore is for ignoring unversioned files that you do not want to commit >> to a repository. >> >> If the files are already committed to the repository, then svn:ignore is not >> applicable. > > Ryan > thanks for the response. > how is the best way not to override files like settings.php when i do > an svn up to my production server? > thanks > Randy Don't keep settings.php in the repository. See: http://subversion.apache.org/faq.html#ignore-commit
Re: cleaning up mergeinfo using svn 1.7
On Fri, Sep 09, 2011 at 03:00:53PM -0400, David Carson wrote: > OK, so let's try again. I've merged a change from another branch, which is > a commit with a single file changed. The result is much better, but let me > verify that I understand my results: > - file a/b/c/foo.c shows the file changes -- OK > - file a/b/c/foo.c also contains svn:mergeinfo changes -- I assume this is > because it happens to be one of the many files that got contaminated with > the property prior to this test. So, since it is part of the changeset for > my merge, the prop has to be updated too. > - directory (call it TLD/) contains svn:mergeinfo changes -- OK > - TLD/a also contains svn:mergeinfo changes -- Same as above. Directory > TLD/a is one of the directories which was previously contaminated, and since > this path is 'involved' in the change, the prop has to be updated. I > wouldn't say the path really involved, except that it is the path on wich > foo.c sits. After all, TLD/a/ is not itself changed. Nonetheless, I can > live with this. This is because it's not about which "objects" (as you called them ealier) are affected by the merge, but which subtrees of the merge target are affected. In your case, it looks as if the target of the merge is the working copy root. An affected subtree of the root is a, an affected subtree of a is b, and so on, until you get to foo.c. If you merge from ^/branch/a/b/c/foo.c into wc-path/a/b/c/foo.c only foo.c should receive mergeinfo updates, because it is the merge target and has no children. > Now, are there any tools to aid in cleanup of the mess? Besides the large > number of files/dirs with the prop attached, the prop itself has a large > number of paths to contend with. There doesn't seem to be any officially sanctioned script. There are various scripts people have written and posted to this list. One is here: http://svn.haxx.se/dev/archive-2009-05/0438.shtml You could try the archive search on svn.haxx.se -- maybe you'll find something useful. However, I would say that the need for such a script implies a lack of functionality in Subversion itself. 'svn merge' does try to elide mergeinfo when subtree mergeinfo becomes redundant, but AFAIK the current implementation is a bit simplistic. It would help if you could present examples where elision does not work for you, so we can fix 'svn merge'. We could allow the existing elision code to be invoked without running a merge. An option like --elide-mergeinfo could be added to the 'svn mergeinfo' command for this purpose. Would this be useful?
Re: cleaning up mergeinfo using svn 1.7
On Sat, Sep 10, 2011 at 12:40:11AM +0200, Stefan Sperling wrote: > It would help if you could present examples where elision does not > work for you, so we can fix 'svn merge'. The following quote from https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_client/mergeinfo.h provides some background on how elision is supposed to work. /* Elide any svn:mergeinfo set on TARGET_WCPATH to its nearest working copy (or possibly repository) ancestor with equivalent mergeinfo. If WC_ELISION_LIMIT_PATH is NULL check up to the root of the working copy or the nearest switched parent for an elision destination, if none is found check the repository, otherwise check as far as WC_ELISION_LIMIT_PATH within the working copy. TARGET_WCPATH and WC_ELISION_LIMIT_PATH, if it exists, must both be absolute or relative to the working directory. Elision occurs if: A) TARGET_WCPATH has empty mergeinfo and no parent path with explicit mergeinfo can be found in either the WC or the repository (WC_ELISION_LIMIT_PATH must be NULL for this to occur). B) TARGET_WCPATH has empty mergeinfo and its nearest parent also has empty mergeinfo. C) TARGET_WCPATH has the same mergeinfo as its nearest parent when that parent's mergeinfo is adjusted for the path difference between the two, e.g.: TARGET_WCPATH= A_COPY/D/H TARGET_WCPATH's mergeinfo= '/A/D/H:3' TARGET_WCPATH nearest parent = A_COPY Parent's mergeinfo = '/A:3' Path differece = 'D/H' Parent's adjusted mergeinfo = '/A/D/H:3' If Elision occurs remove the svn:mergeinfo property from TARGET_WCPATH. */ svn_error_t * svn_client__elide_mergeinfo(const char *target_wcpath, const char *wc_elision_limit_path, svn_client_ctx_t *ctx, apr_pool_t *pool);
customizing svnserve for svn+ssh
I have two sets of repos setup... common repos and user repos. On the machine acting as the svn host, I have the common repos stored in /repos while the user repos are in /home//.repos/ I'm attempting to simplify svn+ssh access such that: svn+ssh:///Code/some_project_reposerves up /repos/Code/some_project_repo svn+ssh:some_project_repo serves up /home//.repos/some_project_repo I took the example of writing a shell script in /usr/local/bin that sets the umask and calls svnserve and modified it to include this path tinkering. Here is that script: ## #!/bin/bash umask 002 PATH="$@" ROOT="/repos" USER=`echo $PATH | /bin/sed "s/^\/\([a-z]*\)\/.*/\1/"` PATTERN="^$USER:" if `/usr/bin/ypcat passwd | /bin/egrep -q $PATTERN` ; then ROOT="/home/$USER/.repos" PATTERN="s/\/$USER//" PATH=`echo $PATH | /bin/sed $PATTERN` fi exec /usr/bin/svnserve "$PATH" -r "$ROOT" # It just compares the first directory passed in against the users in the NIS domain and if it finds a match, builds a new Path and root path to the repos. It works just fine on the command line when I pass it paths and echo back out the parts, but when I attempt to actually run it (by accessing a repo with svn+ssh), $PATH does not get set to the path being passed in... it is just set to '-t'. However, when I try to access a common repo (where PATH is left unadulterated), it serves up the repo just fine. Is the path being passed encoded somehow? Is there are way to access it? thanks, Matt Matthew Beals Michigan Technological University Department of Atmospheric Sciences 1400 Townsend Drive B019a Fisher Hall Houghton, MI 49931 mjbe...@mtu.edu
Re: Searching in SVN
On Sep 9, 2011, at 06:16, Waseem Shahzad wrote: > What we want to same in Tortoise SVN? If you want to learn how to do things with TortoiseSVN, you'll have to ask in a TortoiseSVN support venue. This list is for the base Subversion software only -- the official command line program and libraries.
