Feature request: Easy tree conflick resolve mechanism
Hi, In the old days the .svn folder was in every folder and resolving a tree conflict was as easy as deleting the conflicting folder and doing an update. This solved 90% of our issues. This is no longer possible as the only the .svn is now at the root of the whole project! I assume there are some valid reasons for this, but how do you go about solving tree conflicts efficiently then? We typically get a tree conflict if one guy as deleted a file and another guy as made changes to the file. In the old days, the guy deleting the file could simply remove his folder, do an update and the delete the file again. This is not possible now, if he deletes the folder and does an update subversion won't give him the file back. Svn just keep claiming a tree conflict. What is the best way to resolve this? We did try clean-up and resolve etc.. Regards, Sune
Where is Subversion 1.7's pristine copy of a given file?
I have not upgraded to Subversion 1.7 yet. I'm still on 1.6.17.
One reason is that there is a script I like to use, that I wrote, called
svntwdiff. It goes like this:
$ cat svntwdiff
#!/bin/bash
if [ -z "$1" ]; then
echo "usage: $0 "
exit 1
fi
FILE="$1"
FILEDIR="$(dirname "${FILE}")"
FILEBASE="$(basename "${FILE}")"
SVNDIR="${FILEDIR}/.svn"
ORIGFILE="${SVNDIR}/text-base/${FILEBASE}.svn-base"
if [ ! -f "${FILE}" ]; then
echo "error: ${FILE} doesn't exist"
exit 1
fi
if [ ! -d "${SVNDIR}" ]; then
echo "error: ${SVNDIR} doesn't exist; maybe ${FILEDIR} isn't a working copy"
exit 1
fi
if [ ! -f "${ORIGFILE}" ]; then
echo "error: ${ORIGFILE} doesn't exist; maybe ${FILE} hasn't been committed
yet"
exit 1
fi
twdiff "${FILE}" "${ORIGFILE}"
"twdiff" is a command-line wrapper that comes with the GUI TextWrangler editor;
it opens the two given textfiles in TextWrangler and lets me view and edit the
differences between files. I often use svntwdiff to examine changes in a file
and selectively back out portions of them.
How can I modify this script to be compatible with a Subversion 1.7 format
working copy?
Re: Where is Subversion 1.7's pristine copy of a given file?
Am 13.04.2012 10:55, schrieb Ryan Schmidt: > "twdiff" is a command-line wrapper that comes with the GUI > TextWrangler editor; it opens the two given textfiles in TextWrangler > and lets me view and edit the differences between files. I often use > svntwdiff to examine changes in a file and selectively back out > portions of them. Take a look at "diffuse". That said, I have no idea if diffuse works with SVN 1.7 ... I myself haven't upgraded either. Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: Where is Subversion 1.7's pristine copy of a given file?
Ryan Schmidt wrote on Fri, Apr 13, 2012 at 03:55:34 -0500:
> I have not upgraded to Subversion 1.7 yet. I'm still on 1.6.17.
>
> One reason is that there is a script I like to use, that I wrote, called
> svntwdiff. It goes like this:
>
>
> $ cat svntwdiff
> #!/bin/bash
>
You could use #!/bin/sh here.
> if [ -z "$1" ]; then
> echo "usage: $0 "
> exit 1
> fi
>
> FILE="$1"
> FILEDIR="$(dirname "${FILE}")"
> FILEBASE="$(basename "${FILE}")"
> SVNDIR="${FILEDIR}/.svn"
> ORIGFILE="${SVNDIR}/text-base/${FILEBASE}.svn-base"
>
> if [ ! -f "${FILE}" ]; then
> echo "error: ${FILE} doesn't exist"
> exit 1
> fi
>
> if [ ! -d "${SVNDIR}" ]; then
> echo "error: ${SVNDIR} doesn't exist; maybe ${FILEDIR} isn't a working
> copy"
> exit 1
> fi
>
> if [ ! -f "${ORIGFILE}" ]; then
> echo "error: ${ORIGFILE} doesn't exist; maybe ${FILE} hasn't been
> committed yet"
> exit 1
> fi
>
> twdiff "${FILE}" "${ORIGFILE}"
>
>
> "twdiff" is a command-line wrapper that comes with the GUI
> TextWrangler editor; it opens the two given textfiles in TextWrangler
> and lets me view and edit the differences between files. I often use
> svntwdiff to examine changes in a file and selectively back out
> portions of them.
>
> How can I modify this script to be compatible with a Subversion 1.7
> format working copy?
>
1.7-specific, relies on implementation details:
`svn info`[Working Copy Root Dir]`/.svn/pristine/`svn info`[SHA-1 checksum]`
1.x-compatible:
use 'svn cat' to obtain a tempfile.
1.8:
we might move to compressed pristines. And if we do, we might provide
a "give me a disk path of the uncompressed file that I can pass to my
diff tool" API.
>
Re: Where is Subversion 1.7's pristine copy of a given file?
On Apr 13, 2012, at 04:43, Daniel Shahaf wrote: > Ryan Schmidt wrote on Fri, Apr 13, 2012 at 03:55:34 -0500: > >> How can I modify this script to be compatible with a Subversion 1.7 >> format working copy? > > 1.7-specific, relies on implementation details: > `svn info`[Working Copy Root Dir]`/.svn/pristine/`svn info`[SHA-1 checksum]` Thanks! That was the info I needed. > 1.x-compatible: > use 'svn cat' to obtain a tempfile. That's a good idea. It sounds like this would be less work and automatically backward- and future-compatible. > 1.8: > we might move to compressed pristines. And if we do, we might provide > a "give me a disk path of the uncompressed file that I can pass to my > diff tool" API.
Re: Where is Subversion 1.7's pristine copy of a given file?
Ryan Schmidt wrote on Fri, Apr 13, 2012 at 04:55:17 -0500: > > On Apr 13, 2012, at 04:43, Daniel Shahaf wrote: > > > 1.x-compatible: > > use 'svn cat' to obtain a tempfile. > > That's a good idea. It sounds like this would be less work and > automatically backward- and future-compatible. Indeed. Just make sure to pass @BASE to avoid a round trip to the server. (you may want to double-check that it indeed avoids a server round-trip in that case; it should, but I never verified whether it does.)
Re: Where is Subversion 1.7's pristine copy of a given file?
On Apr 13, 2012, at 04:58, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Fri, Apr 13, 2012 at 04:55:17 -0500:
>>
>> On Apr 13, 2012, at 04:43, Daniel Shahaf wrote:
>>
>>> 1.x-compatible:
>>> use 'svn cat' to obtain a tempfile.
>>
>> That's a good idea. It sounds like this would be less work and
>> automatically backward- and future-compatible.
>
> Indeed. Just make sure to pass @BASE to avoid a round trip to the server.
>
> (you may want to double-check that it indeed avoids a server round-trip
> in that case; it should, but I never verified whether it does.)
There didn't appear to be any traffic to my repository regardless if I added
@BASE or not but I added it anyway since you said to.
Here's the new script for anyone interested. Thanks again for your help.
$ cat svntwdiff
#!/bin/bash
# http://svn.haxx.se/users/archive-2012-04/0090.shtml
if [ -z "$1" ]; then
echo "usage: $0 "
exit 1
fi
FILE="$1"
if [ ! -f "${FILE}" ]; then
echo "error: ${FILE} doesn't exist"
exit 1
fi
if [ -z "${TMPDIR}" ]; then
TMPDIR=/tmp
fi
svn info "${FILE}" >/dev/null || exit $?
TMPFILE="$(mktemp "${TMPDIR}/svntwdiff.XX")"
svn cat "${FILE}"@BASE > "${TMPFILE}"
twdiff --wait --resume "${FILE}" "${TMPFILE}"
rm -f "${TMPFILE}"
Re: Feature request: Easy tree conflick resolve mechanism
On Fri, Apr 13, 2012 at 10:27:15AM +0200, Sune Fischer wrote: > Hi, > > In the old days the .svn folder was in every folder and resolving a > tree conflict was as easy as deleting the conflicting folder and > doing an update. This solved 90% of our issues. > This is no longer possible as the only the .svn is now at the root > of the whole project! Please keep in mind that blowing away .svn meta-data has never been a supported way of resolving conflicts, or performing any Subversion operation, for that matter. > I assume there are some valid reasons for this, but how do you go > about solving tree conflicts efficiently then? This depends on the kind of conflict, and the resolution you'd like to achieve. There is no general recipe that will resolve any tree conflict. You need to consider each tree conflict on a case-by-case basis and reason about how to resolve it. > We typically get a tree conflict if one guy as deleted a file and > another guy as made changes to the file. > In the old days, the guy deleting the file could simply remove his > folder, do an update and the delete the file again. > This is not possible now, if he deletes the folder and does an > update subversion won't give him the file back. Svn just keep > claiming a tree conflict. > > What is the best way to resolve this? > We did try clean-up and resolve etc.. I'm not quite sure I understand your conflict scenario. So you're saying you get an incoming edit on top of a local delete? And the desired resolution result is that the file should be deleted? This sounds too simple to cause confusion about how to resolve the conflict because this scenario is in fact trivial to resolve: # The file alpha is locally deleted $ svn status D alpha # An update brings down an edit on top of it $ svn update Updating '.': C alpha At revision 3. Summary of conflicts: Tree conflicts: 1 # Now we have a conflict marked in the working copy $ svn status D C alpha > local delete, incoming edit upon update Summary of conflicts: Tree conflicts: 1 # We decide that alpha should be deleted. And it still is deleted... $ ls beta epsilon/ gamma/ # ... so the current working copy state is what we want to resolve to $ svn resolve --accept working alpha Resolved conflicted state of 'alpha' $ svn status D alpha If the above doesn't match your situation, can you please take the time to create a transcript that shows your situation, similar to what I did above? Because minute details matter a lot when discussion these kinds of things a simple transcript often says a lot more than a thousand written words attempting to describe the situation. Thanks.
Re: Where is Subversion 1.7's pristine copy of a given file?
Ryan Schmidt wrote on Fri, Apr 13, 2012 at 05:28:41 -0500: > > On Apr 13, 2012, at 04:58, Daniel Shahaf wrote: > > > Ryan Schmidt wrote on Fri, Apr 13, 2012 at 04:55:17 -0500: > >> > >> On Apr 13, 2012, at 04:43, Daniel Shahaf wrote: > >> > >>> 1.x-compatible: > >>> use 'svn cat' to obtain a tempfile. > >> > >> That's a good idea. It sounds like this would be less work and > >> automatically backward- and future-compatible. > > > > Indeed. Just make sure to pass @BASE to avoid a round trip to the server. > > > > (you may want to double-check that it indeed avoids a server round-trip > > in that case; it should, but I never verified whether it does.) > > There didn't appear to be any traffic to my repository regardless if > I added @BASE or not but I added it anyway since you said to. Well, it doesn't hurt, but it's not necessary either because the peg revision for non-URL targets defaults to @BASE. You're welcome.
RE: Feature request: Easy tree conflick resolve mechanism
> -Original Message- > From: Sune Fischer [mailto:suneprogram...@gmail.com] > Sent: vrijdag 13 april 2012 10:27 > To: users@subversion.apache.org > Subject: Feature request: Easy tree conflick resolve mechanism > > Hi, > > In the old days the .svn folder was in every folder and resolving a tree > conflict was as easy as deleting the conflicting folder and doing an > update. This solved 90% of our issues. > This is no longer possible as the only the .svn is now at the root of > the whole project! > I assume there are some valid reasons for this, but how do you go about > solving tree conflicts efficiently then? > > We typically get a tree conflict if one guy as deleted a file and > another guy as made changes to the file. > In the old days, the guy deleting the file could simply remove his > folder, do an update and the delete the file again. > This is not possible now, if he deletes the folder and does an update > subversion won't give him the file back. Svn just keep claiming a tree > conflict. > > What is the best way to resolve this? > We did try clean-up and resolve etc.. svn revert -R will have the same result as you had in 1.6 when you removed the folder and then performed the update. The data that got missing in 1.6 when you got the tree conflict is now already stored in the pristine store so the update is no longer necessary, but it doesn't hurt to update anyway. In 1.6 you should have resolved the tree conflict in the same way, but the recovering process from missing data was about the same thing. In 1.7 we can usually also recover from the missing conflicted data, so you get the conflicted data back. Bert
svnrdump fails when access control restrictions are in place
svnrdump fails when access control restrictions are in place on the server and the --incremental option is not used. The message returned is "authorization failed". This does not occur when the --incremental option occurs. The svnrdump command is version 1.7.2.
Re: svnrdump fails when access control restrictions are in place
When --incremental isn't used svnrdump tries to dump the full tree and runs into the authz restrictions. Do you have a suggestion for an alternative behaviour? Andrew Sasak wrote on Fri, Apr 13, 2012 at 11:58:50 -0400: > svnrdump fails when access control restrictions are in place on the > server and the --incremental option is not used. The message returned > is "authorization failed". This does not occur when the --incremental > option occurs. The svnrdump command is version 1.7.2.
Re: svnrdump fails when access control restrictions are in place
When --incremental is used, dump records all changes that the user has access to. When --incremental is used, I think dump should dump the whole tree that the user has access to. I can imagine that this would be a non-trivial change for an uncommon use case. On Fri, Apr 13, 2012 at 1:25 PM, Daniel Shahaf wrote: > When --incremental isn't used svnrdump tries to dump the full tree and > runs into the authz restrictions. Do you have a suggestion for an > alternative behaviour? > > Andrew Sasak wrote on Fri, Apr 13, 2012 at 11:58:50 -0400: >> svnrdump fails when access control restrictions are in place on the >> server and the --incremental option is not used. The message returned >> is "authorization failed". This does not occur when the --incremental >> option occurs. The svnrdump command is version 1.7.2.
Re: Subversion 1.6.18 released
On Thu, Apr 12, 2012 at 9:15 AM, Stefan Sperling wrote: > I'm happy to announce the release of Apache Subversion 1.6.18. > Cool. I got 1.6.17 in the pipeline for Repoforge publication, and I can build and test this minor release for RHEL compatibility. It'll take a few hours for all the environments I have on hand to build for.. What's going on with Apache bundling? I can change the downloadable tarball references in the .spec files over at http://www.github.com;nkadel/, but what's going on there?
