Re: hot-backup.py
On Feb 22, 2012, at 3:43 , Nico Kadel-Garcia wrote: On Tue, Feb 21, 2012 at 7:27 PM, Salari, Kamran kamran.sal...@philips.com wrote: Hi everyone, I am new to Subversion, and I am using TortoiseSVN-1.7.3 and Slik-Subversion-1.7.2 on my XP system (Service Pack 3). I would like to know if there is a Windows version of “hot-backup.py” which I can use. It appears the script in “tools\backup” is written for a Unix environment. Actually, the hot-backup.py script is cross-platform. It uses Python's subprocess module, which works fine on Windows (it's used in the Subversion test suite). I just tested the script again on Windows 7, just to be sure. Enter the absolute paths to svnlook.exe and svnadmin.exe at the top of the script, e.g., svnlook = rC:\Program Files\Subversion\bin\svnlook.exe and you're all set. Cheers, Steve
Re: svn:externals parser API
Stefan Sperling wrote on Wed, Feb 22, 2012 at 00:08:35 +0100:
On Tue, Feb 21, 2012 at 11:50:54PM +0100, Stefan Sperling wrote:
I think svn_wc_parse_externals_description3() should do what you need.
Does this help you?
The function is mapped in the python bindings:
import svn.wc
svn.wc.svn_wc_parse_externals_description3
function svn_wc_parse_externals_description3 at 0x20779a758
Hmmm... my suggestion probably won't work.
The function doesn't seem to be usable.
svn.wc.svn_wc_parse_externals_description3(/tmp, ^/branch/gamma foo,
0)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.7/site-packages/libsvn/wc.py, line 398, in
svn_w
c_parse_externals_description3
return apply(_wc.svn_wc_parse_externals_description3, args)
ValueError: svn_wc_parse_externals_description3 is not implemented yet
But the 1.4 version of this function is working:
e = svn.wc.svn_wc_parse_externals_description(/tmp, ^/branch/gamma
foo)
e
{'foo': libsvn.wc.svn_wc_external_item_t; proxy of Swig Object of type
'svn_wc
_external_item_t *' at 0x2083e50c0 }
e['foo']
libsvn.wc.svn_wc_external_item_t; proxy of Swig Object of type
'svn_wc_externa
l_item_t *' at 0x2083e50c0
e['foo'].target_dir
'foo'
e['foo'].url
'^/branch/gamma'
e['foo'].revision
libsvn.core.svn_opt_revision_t; proxy of Swig Object of type
'svn_opt_revision_t *' at 0x2043d90d0
But that doesn't provide you with the enhancements of the 1.5 syntax,
e.g. peg-revision support.
I am not a bindings expert so I don't know what we'd need to do to make
the newer variants of this function work from the bindings.
Based the difference between the signatures of the
svn_wc_parse_externals_description() and
svn_wc_parse_externals_description2(), I would suspect that someone
needs to provide a Python implementation of the following typemap:
#ifdef SWIGRUBY
%typemap(argout) apr_array_header_t **externals_p {
%append_output(svn_swig_rb_apr_array_to_array_external_item2(*$1));
}
#endif
Daniel
(not a swig expert, either)
Re: svn:externals parser API
Daniel Shahaf wrote on Wed, Feb 22, 2012 at 11:31:00 +0200:
Stefan Sperling wrote on Wed, Feb 22, 2012 at 00:08:35 +0100:
On Tue, Feb 21, 2012 at 11:50:54PM +0100, Stefan Sperling wrote:
I think svn_wc_parse_externals_description3() should do what you need.
Does this help you?
The function is mapped in the python bindings:
import svn.wc
svn.wc.svn_wc_parse_externals_description3
function svn_wc_parse_externals_description3 at 0x20779a758
Hmmm... my suggestion probably won't work.
The function doesn't seem to be usable.
svn.wc.svn_wc_parse_externals_description3(/tmp, ^/branch/gamma
foo, 0)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.7/site-packages/libsvn/wc.py, line 398, in
svn_w
c_parse_externals_description3
return apply(_wc.svn_wc_parse_externals_description3, args)
ValueError: svn_wc_parse_externals_description3 is not implemented yet
But the 1.4 version of this function is working:
e = svn.wc.svn_wc_parse_externals_description(/tmp, ^/branch/gamma
foo)
e
{'foo': libsvn.wc.svn_wc_external_item_t; proxy of Swig Object of type
'svn_wc
_external_item_t *' at 0x2083e50c0 }
e['foo']
libsvn.wc.svn_wc_external_item_t; proxy of Swig Object of type
'svn_wc_externa
l_item_t *' at 0x2083e50c0
e['foo'].target_dir
'foo'
e['foo'].url
'^/branch/gamma'
e['foo'].revision
libsvn.core.svn_opt_revision_t; proxy of Swig Object of type
'svn_opt_revision_t *' at 0x2043d90d0
But that doesn't provide you with the enhancements of the 1.5 syntax,
e.g. peg-revision support.
I am not a bindings expert so I don't know what we'd need to do to make
the newer variants of this function work from the bindings.
Based the difference between the signatures of the
svn_wc_parse_externals_description() and
svn_wc_parse_externals_description2(), I would suspect that someone
needs to provide a Python implementation of the following typemap:
#ifdef SWIGRUBY
%typemap(argout) apr_array_header_t **externals_p {
%append_output(svn_swig_rb_apr_array_to_array_external_item2(*$1));
}
#endif
Done in r1292223:
% PYTHONPATH=$prefix/svn-t1/lib/svn-python/ python -c \
'import svn,svn.wc; print
svn.wc.svn_wc_parse_externals_description3(,,1)'
[]
%
It will be available in 1.8.0.
(perhaps we should relax our compat guidelines to allow adding exposed
APIs to the bindings in patch releases?)
Daniel
(not a swig expert, either)
Re: svn:externals parser API
Am 22.02.2012 um 11:16 schrieb Daniel Shahaf:
Daniel Shahaf wrote on Wed, Feb 22, 2012 at 11:31:00 +0200:
Stefan Sperling wrote on Wed, Feb 22, 2012 at 00:08:35 +0100:
On Tue, Feb 21, 2012 at 11:50:54PM +0100, Stefan Sperling wrote:
I think svn_wc_parse_externals_description3() should do what you need.
Does this help you?
The function is mapped in the python bindings:
import svn.wc
svn.wc.svn_wc_parse_externals_description3
function svn_wc_parse_externals_description3 at 0x20779a758
Based the difference between the signatures of the
svn_wc_parse_externals_description() and
svn_wc_parse_externals_description2(), I would suspect that someone
needs to provide a Python implementation of the following typemap:
#ifdef SWIGRUBY
%typemap(argout) apr_array_header_t **externals_p {
%append_output(svn_swig_rb_apr_array_to_array_external_item2(*$1));
}
#endif
Done in r1292223:
% PYTHONPATH=$prefix/svn-t1/lib/svn-python/ python -c \
'import svn,svn.wc; print
svn.wc.svn_wc_parse_externals_description3(,,1)'
[]
%
It will be available in 1.8.0.
(perhaps we should relax our compat guidelines to allow adding exposed
APIs to the bindings in patch releases?)
Hi,
this sound pretty good, thanks for the quick replies. If I understand this
correctly (I havent used SWIG before), we could get this in the Perl bindings
by adding a similar typemap for Perl?
I won't attempt it myself, since I know neither Perl, nor swig, but I will head
over to the git folks and tell them that this should be easy to add.
Cheers,
Nikolaus
(please CC on answers, I'm not subscribed to the list - thanks :-) )
Re: svn:externals parser API
Nikolaus Demmel wrote on Wed, Feb 22, 2012 at 14:22:26 +0100:
Am 22.02.2012 um 11:16 schrieb Daniel Shahaf:
Daniel Shahaf wrote on Wed, Feb 22, 2012 at 11:31:00 +0200:
Stefan Sperling wrote on Wed, Feb 22, 2012 at 00:08:35 +0100:
On Tue, Feb 21, 2012 at 11:50:54PM +0100, Stefan Sperling wrote:
I think svn_wc_parse_externals_description3() should do what you need.
Does this help you?
The function is mapped in the python bindings:
import svn.wc
svn.wc.svn_wc_parse_externals_description3
function svn_wc_parse_externals_description3 at 0x20779a758
Based the difference between the signatures of the
svn_wc_parse_externals_description() and
svn_wc_parse_externals_description2(), I would suspect that someone
needs to provide a Python implementation of the following typemap:
#ifdef SWIGRUBY
%typemap(argout) apr_array_header_t **externals_p {
%append_output(svn_swig_rb_apr_array_to_array_external_item2(*$1));
}
#endif
Done in r1292223:
% PYTHONPATH=$prefix/svn-t1/lib/svn-python/ python -c \
'import svn,svn.wc; print
svn.wc.svn_wc_parse_externals_description3(,,1)'
[]
%
It will be available in 1.8.0.
(perhaps we should relax our compat guidelines to allow adding exposed
APIs to the bindings in patch releases?)
Hi,
this sound pretty good, thanks for the quick replies. If I understand this
correctly (I havent used SWIG before), we could get this in the Perl bindings
by adding a similar typemap for Perl?
Sounds right. (I haven't checked whether something beyond a typemap
would be needed for Perl.)
I won't attempt it myself, since I know neither Perl, nor swig, but I will
head over to the git folks and tell them that this should be easy to add.
Sure.
http://subversion.apache.org/patches
http://github.com/apache/subversion
:-)
Cheers,
Nikolaus
(please CC on answers, I'm not subscribed to the list - thanks :-) )
commit hooks - is there a hook which is called after commit even if its not successful
Hi, the http://svnbook.red-bean.com/en/1.6/svn.ref.reposhooks.html book tells about the various post-* hooks. But those one are called on successfull operations. Whats the way to implement a hook, which is called after commit - it does not matter if successful or failed - the hook must be able to figure out if all went fine or something went wrong. Can this be done or is this not possible at the moment? regards Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Paul Burba ptbu...@gmail.com writes:
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
to the dev list.
Investigating...
svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
'C:\t\wc\externals-container-copy': Access is denied.
I suspect this is a directory move. Perhaps the wc.db file of the
external is still open? Can a directory be renamed on Windows when one
of the files inside it is still open?
Not in my experience.
I added an issue for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4123
and a test also: http://svn.apache.org/viewvc?view=revisionrevision=1292090
The attached patch fixes this problem on Windows. Could any wc-ng
gurus take a look and see if this seems reasonable?
[[[
Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
* subversion/include/private/svn_wc_private.h
(svn_wc__externals_close): New declaration.
* subversion/libsvn_wc/externals.c
(svn_wc__externals_close): New definition.
* subversion/libsvn_client/copy.c
(repos_to_wc_copy_single): Use new function to close handles to
externals' DB files before trying to rename the whole temp WC.
* subversion/tests/cmdline/externals_tests.py
(url_to_wc_copy_of_externals): Remove XFail decorator and update comments
re failure status.
]]]
Even with this fix I'm still seeing odd behavior post-copy (the
following example uses a WC-to-WC copy, but the same problem occurs
with a URL-to-WC copy):
### We have a working copy at a uniform revision with an external:
svn up -q
svn st
X A\C\external
Performing status on external item at 'A\C\external':
svn pl -vR
Properties on 'A\C':
svn:externals
^/A/D/G external
### We copy the directory with the external definition:
svn copy A/C WC-to-WC-Copy-of-C
A WC-to-WC-Copy-of-C
### But the external shows up as unversioned:
svn st
X A\C\external
A +WC-to-WC-Copy-of-C
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
### Even if we commit an update the WC we see the same problem:
svn ci -m
Adding WC-to-WC-Copy-of-C
Committed revision 3.
svn up
Updating '.':
Fetching external item into 'WC-to-WC-Copy-of-C\external':
External at revision 3.
Fetching external item into 'A\C\external':
External at revision 3.
At revision 3.
svn st
X A\C\external
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
To fix this we need to remove the external via the OS then update to
restore it (note that this problem occurs without my patch applied, so
this is a separate issue).
Paul
Index: subversion/include/private/svn_wc_private.h
===
--- subversion/include/private/svn_wc_private.h (revision 1292379)
+++ subversion/include/private/svn_wc_private.h (working copy)
@@ -263,6 +263,15 @@
apr_pool_t *result_pool,
apr_pool_t *scratch_pool);
+/* Close the DBs for any externals under LOCAL_ABSPATH. Detection of
+ externals is as per svn_wc__externals_gather_definitions.
+
+ Perform temporary allocations in SCRATCH_POOL. */
+svn_error_t *
+svn_wc__externals_close(const char *local_abspath,
+svn_wc_context_t *wc_ctx,
+apr_pool_t *scratch_pool);
+
/** Set @a *tree_conflict to a newly allocated @c
* svn_wc_conflict_description_t structure describing the tree
* conflict state of @a victim_abspath, or to @c NULL if @a victim_abspath
Index: subversion/libsvn_client/copy.c
===
--- subversion/libsvn_client/copy.c (revision 1292379)
+++ subversion/libsvn_client/copy.c (working copy)
@@ -1519,6 +1519,17 @@
ctx-notify_baton2 = old_notify_baton2;
SVN_ERR(err);
+
+#ifdef WIN32
+if (!ignore_externals)
+ {
+/* Issue #4123: We may still hold file handles to the databases
+ for externals under TMP_ABSPATH. We need to release these
+ handles before we move TMP_ABSPATH below or Windows will
+ raise an ERROR_ACCESS_DENIED error. */
+SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx-wc_ctx, pool));
+ }
+#endif
}
/* Schedule dst_path for addition in parent, with copy history.
Index: subversion/libsvn_wc/externals.c
===
---
RE: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
-Original Message- From: Paul Burba [mailto:ptbu...@gmail.com] Sent: woensdag 22 februari 2012 17:42 To: Nico Kadel-Garcia Cc: Philip Martin; C. Michael Pilato; Subversion Development; Alexey 0 Moudrick; users@subversion.apache.org Subject: Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin philip.mar...@wandisco.com wrote: Paul Burba ptbu...@gmail.com writes: I'm able to replicate this failure on my Windows box with my own builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as expected with 1.6.17, so this appears to be a regression. Moving back to the dev list. Investigating... svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to 'C:\t\wc\externals-container-copy': Access is denied. I suspect this is a directory move. Perhaps the wc.db file of the external is still open? Can a directory be renamed on Windows when one of the files inside it is still open? Not in my experience. I added an issue for this: http://subversion.tigris.org/issues/show_bug.cgi?id=4123 and a test also: http://svn.apache.org/viewvc?view=revisionrevision=1292090 The attached patch fixes this problem on Windows. Could any wc-ng gurus take a look and see if this seems reasonable? [[[ Fix issue #4123 'URL-to-WC copy of externals fails on Windows'. * subversion/include/private/svn_wc_private.h (svn_wc__externals_close): New declaration. * subversion/libsvn_wc/externals.c (svn_wc__externals_close): New definition. * subversion/libsvn_client/copy.c (repos_to_wc_copy_single): Use new function to close handles to externals' DB files before trying to rename the whole temp WC. * subversion/tests/cmdline/externals_tests.py (url_to_wc_copy_of_externals): Remove XFail decorator and update comments re failure status. ]]] I don't think the code should be conditional for Windows. On other platforms we should also close databases that we are about to move as our references to it (via abspath) are no longer valid anyway. (And who knows what sqlite does with the path internally...) I don't know what svn_wc__db_drop_root() does exactly, but the code should also flush some of the svn_wc__db_t internal state which maps abspaths to db handles. It might even be easier to resolve this problem this way: just release all databases below a specific path? Bert Even with this fix I'm still seeing odd behavior post-copy (the following example uses a WC-to-WC copy, but the same problem occurs with a URL-to-WC copy): ### We have a working copy at a uniform revision with an external: svn up -q svn st X A\C\external Performing status on external item at 'A\C\external': svn pl -vR Properties on 'A\C': svn:externals ^/A/D/G external ### We copy the directory with the external definition: svn copy A/C WC-to-WC-Copy-of-C A WC-to-WC-Copy-of-C ### But the external shows up as unversioned: svn st X A\C\external A +WC-to-WC-Copy-of-C ? WC-to-WC-Copy-of-C\external Performing status on external item at 'WC-to-WC-Copy-of-C\external': Performing status on external item at 'A\C\external': ### Even if we commit an update the WC we see the same problem: svn ci -m Adding WC-to-WC-Copy-of-C Committed revision 3. svn up Updating '.': Fetching external item into 'WC-to-WC-Copy-of-C\external': External at revision 3. Fetching external item into 'A\C\external': External at revision 3. At revision 3. svn st X A\C\external ? WC-to-WC-Copy-of-C\external Performing status on external item at 'WC-to-WC-Copy-of-C\external': Performing status on external item at 'A\C\external': To fix this we need to remove the external via the OS then update to restore it (note that this problem occurs without my patch applied, so this is a separate issue). Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
On Wed, Feb 22, 2012 at 11:42 AM, Paul Burba ptbu...@gmail.com wrote: Even with this fix I'm still seeing odd behavior post-copy (the following example uses a WC-to-WC copy, but the same problem occurs with a URL-to-WC copy): . SNIP . To fix this we need to remove the external via the OS then update to restore it (note that this problem occurs without my patch applied, so this is a separate issue). Added a new issue for this http://subversion.tigris.org/issues/show_bug.cgi?id=4125 Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
Paul Burba ptbu...@gmail.com writes:
Index: subversion/libsvn_client/copy.c
===
--- subversion/libsvn_client/copy.c (revision 1292379)
+++ subversion/libsvn_client/copy.c (working copy)
@@ -1519,6 +1519,17 @@
ctx-notify_baton2 = old_notify_baton2;
SVN_ERR(err);
+
+#ifdef WIN32
+if (!ignore_externals)
+ {
+/* Issue #4123: We may still hold file handles to the databases
+ for externals under TMP_ABSPATH. We need to release these
+ handles before we move TMP_ABSPATH below or Windows will
+ raise an ERROR_ACCESS_DENIED error. */
+SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx-wc_ctx, pool));
+ }
+#endif
I'm not sure why this would be windows specific. Yes, Linux lets us
move the dir with the handle open but I think it would be an error for
the Subversion client to use the handle after the move.
Is this the best way to do it? It isn't what I was expecting. I was
expecting the checkout code to explicitly close the handles it was
responsible for opening. Then the copy code would not have to do
anything special.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Subversion restore
Hello. I've read through some threads, but it seems that the scenarios assume I have valid repo dumps. I do not. What I have is a new server, and the backups of the old server. I installed what I can only assume is a much newer version of subversion on the new server. I copied my repo directory to the new server and tried an import, which failed with svn: Expected version '3' of repository; found version '5'. In fact, it says that no matter what svn command I put in. I am running svn, version 1.1.4 (r13838) Can anyone please point me down the right path? -- View this message in context: http://old.nabble.com/Subversion-restore-tp33372376p33372376.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Subversion restore
On 2/22/2012 11:11 AM, svenk1 wrote: Hello. I've read through some threads, but it seems that the scenarios assume I have valid repo dumps. I do not. What I have is a new server, and the backups of the old server. I installed what I can only assume is a much newer version of subversion on the new server. I copied my repo directory to the new server and tried an import, which failed with svn: Expected version '3' of repository; found version '5'. In fact, it says that no matter what svn command I put in. I am running svn, version 1.1.4 (r13838) The current version of svn is 1.7.3... sounds like you installed a much *older* version of svn on the new server. The error message means that the repo is for a newer version of svn. Either install svn 1.7.3, or at least find out what version you were running before, and install the same version. (But I'd recommend installing 1.7.3). -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 36 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Subversion restore
On Wed, Feb 22, 2012 at 11:11 AM, svenk1 bob.tro...@ketchum.com wrote: Hello. I've read through some threads, but it seems that the scenarios assume I have valid repo dumps. I do not. What I have is a new server, and the backups of the old server. I installed what I can only assume is a much newer version of subversion on the new server. I copied my repo directory to the new server and tried an import, which failed with svn: Expected version '3' of repository; found version '5'. In fact, it says that no matter what svn command I put in. I am running svn, version 1.1.4 (r13838) Can anyone please point me down the right path? That's not much of a description of what you have or what you've done. Can you provide some more details about the platforms and versions involved. For one thing, an 'import' doesn't make much sense in the context of 2 repositories, and neither does an error message about a too-new repository from what you think is a newer program.In any case, I'd try to svnadmin dump the old copy of the repo. If that works you can follow the standard instructions. If not, try to restore your old version of svnadmin - but from your error message above, I think you may already be confused about what versions you have installed and running. -- Les Mikesell lesmikes...@gmail.com
Re: commit hooks - is there a hook which is called after commit even if its not successful
On Feb 22, 2012, at 09:23, Torsten Krah wrote: the http://svnbook.red-bean.com/en/1.6/svn.ref.reposhooks.html book tells about the various post-* hooks. But those one are called on successfull operations. Whats the way to implement a hook, which is called after commit - it does not matter if successful or failed - the hook must be able to figure out if all went fine or something went wrong. Can this be done or is this not possible at the moment? I don't think this is possible. You have the pre-commit hook, which fires before the commit; you can examine the commit and reject it at that time if desired. Assuming you don't reject it, the commit goes to Subversion's engine which writes it to the repository. Then it calls the post-commit hook, where you can do additional operations like send email notifications about the commit. What circumstance to you envision in which the commit is not successful, and what automated action do you intend to perform as a result?
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL - WC if URL contains externals
On Wed, Feb 22, 2012 at 12:05 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Paul Burba ptbu...@gmail.com writes:
Index: subversion/libsvn_client/copy.c
===
--- subversion/libsvn_client/copy.c (revision 1292379)
+++ subversion/libsvn_client/copy.c (working copy)
@@ -1519,6 +1519,17 @@
ctx-notify_baton2 = old_notify_baton2;
SVN_ERR(err);
+
+#ifdef WIN32
+ if (!ignore_externals)
+ {
+ /* Issue #4123: We may still hold file handles to the databases
+ for externals under TMP_ABSPATH. We need to release these
+ handles before we move TMP_ABSPATH below or Windows will
+ raise an ERROR_ACCESS_DENIED error. */
+ SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx-wc_ctx,
pool));
+ }
+#endif
I'm not sure why this would be windows specific. Yes, Linux lets us
move the dir with the handle open but I think it would be an error for
the Subversion client to use the handle after the move.
Hi Philip,
OK, both you and Bert pointed this out, so it's gone.
Is this the best way to do it? It isn't what I was expecting. I was
expecting the checkout code to explicitly close the handles it was
responsible for opening. Then the copy code would not have to do
anything special.
Are you thinking within svn_client__checkout_internal or from its
caller, like the attached patch?
Paul
Index: subversion/include/private/svn_wc_private.h
===
--- subversion/include/private/svn_wc_private.h (revision 1292379)
+++ subversion/include/private/svn_wc_private.h (working copy)
@@ -263,6 +263,15 @@
apr_pool_t *result_pool,
apr_pool_t *scratch_pool);
+/* Close the DB for LOCAL_ABSPATH. Perform temporary allocations in
+ SCRATCH_POOL.
+
+ Wraps svn_wc__db_drop_root(). */
+svn_error_t *
+svn_wc__close_db(const char *external_abspath,
+ svn_wc_context_t *wc_ctx,
+ apr_pool_t *scratch_pool);
+
/** Set @a *tree_conflict to a newly allocated @c
* svn_wc_conflict_description_t structure describing the tree
* conflict state of @a victim_abspath, or to @c NULL if @a victim_abspath
Index: subversion/libsvn_client/externals.c
===
--- subversion/libsvn_client/externals.c(revision 1292379)
+++ subversion/libsvn_client/externals.c(working copy)
@@ -299,6 +299,9 @@
external_peg_rev,
external_rev,
pool));
+/* Issue #4123: We don't need to keep the newly checked out external's
+ DB open. */
+SVN_ERR(svn_wc__close_db(local_abspath, ctx-wc_ctx, pool));
}
return SVN_NO_ERROR;
Index: subversion/libsvn_wc/externals.c
===
--- subversion/libsvn_wc/externals.c(revision 1292379)
+++ subversion/libsvn_wc/externals.c(working copy)
@@ -1363,6 +1363,16 @@
}
}
+svn_error_t *
+svn_wc__close_db(const char *external_abspath,
+ svn_wc_context_t *wc_ctx,
+ apr_pool_t *scratch_pool)
+{
+ SVN_ERR(svn_wc__db_drop_root(wc_ctx-db, external_abspath,
+ scratch_pool));
+ return SVN_NO_ERROR;
+}
+
/* Return the scheme of @a uri in @a scheme allocated from @a pool.
If @a uri does not appear to be a valid URI, then @a scheme will
not be updated. */
RE: hot-backup.py
Thanks for responding to my question. I changed the paths for svnlook.exe and svnadmin.exe to their absolute paths. I used the following command, hot-backup.py --help, to check the program. I got the following error L:\CONTROLS\Kamran\Subversion\BackupScripthot-backup.py --help File L:\CONTROLS\Kamran\Subversion\BackupScript\hot-backup.py, line 73 chmod_tree(dirname, 0666, 0666) ^ SyntaxError: invalid token I do not know why it is not just printing the Usage information and exit. I tried backing up the repository, I got the same error. Thanks, Kamran -Original Message- From: Stephen Butler [mailto:sbut...@elego.de] Sent: Wednesday, February 22, 2012 12:53 AM To: Nico Kadel-Garcia Cc: Salari, Kamran; users@subversion.apache.org users Subject: Re: hot-backup.py On Feb 22, 2012, at 3:43 , Nico Kadel-Garcia wrote: On Tue, Feb 21, 2012 at 7:27 PM, Salari, Kamran kamran.sal...@philips.com wrote: Hi everyone, I am new to Subversion, and I am using TortoiseSVN-1.7.3 and Slik-Subversion-1.7.2 on my XP system (Service Pack 3). I would like to know if there is a Windows version of hot-backup.py which I can use. It appears the script in tools\backup is written for a Unix environment. Actually, the hot-backup.py script is cross-platform. It uses Python's subprocess module, which works fine on Windows (it's used in the Subversion test suite). I just tested the script again on Windows 7, just to be sure. Enter the absolute paths to svnlook.exe and svnadmin.exe at the top of the script, e.g., svnlook = rC:\Program Files\Subversion\bin\svnlook.exe and you're all set. Cheers, Steve The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Re: Subversion restore
On Wed, Feb 22, 2012 at 12:11 PM, svenk1 bob.tro...@ketchum.com wrote: Hello. I've read through some threads, but it seems that the scenarios assume I have valid repo dumps. I do not. What I have is a new server, and the backups of the old server. I installed what I can only assume is a much newer version of subversion on the new server. I copied my repo directory to the new server and tried an import, which failed with svn: Expected version '3' of repository; found version '5'. In fact, it says that no matter what svn command I put in. I am running svn, version 1.1.4 (r13838) Can anyone please point me down the right path? You have the exact opposite problem of the one you think you have. Your old server was running a modern version of Subversion and so the created repositories have format 5. Your new server has an ancient version of Subversion that is unable to read the newer format. Upgrade the Subversion binaries on your new server and you will be all set. The current version is 1.7.3, but using a 1.6.x version would also be OK. Do not use anything older than that. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: hot-backup.py
On Tue, Feb 21, 2012 at 7:27 PM, Salari, Kamran kamran.sal...@philips.com wrote: I am new to Subversion, and I am using TortoiseSVN-1.7.3 and Slik-Subversion-1.7.2 on my XP system (Service Pack 3). I would like to know if there is a Windows version of “hot-backup.py” which I can use. It appears the script in “tools\backup” is written for a Unix environment. You might want to consider installing and running Subversion Edge on your server: http://www.open.collab.net/products/subversion/SVNedge.html It provides a web based UI for managing your repositories and one of the features it provides is scheduled backups. So you can schedule a hot copy backup to run hourly/daily as well as how many versions to keep. Then you do not have to mess around with scripts and Windows task schedulers. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Subversion restore
On 2/22/2012 9:52 AM, svenk1 wrote: Les - It is an older Centos 4.8 install. I ran yum install subversion and copied the repository directory to the new server. I tried the import because I didnt have dumps. I don't know what I am doing. I tried the dump but got the same message svnadmin dump /svn svn: Expected version '3' of repository; found version '5' Dave - I just installed subversion by running yum install subversion on this older centos 4.8 install. Is there a way I can tell what version the repository is? I would prefer to install the same version to avoid conflicts with the older OS. http://svn.apache.org/repos/asf/subversion/trunk/notes/repos_upgrade_HOWTO Repository version 5 corresponds to Subversion 1.4 and later. Your CentOS 4.8 installation has Subversion 1.3.x in all likelihood if you're getting this message. Try svn --version; it will tell you what's been installed. Don't continue to use an old version of Subversion; upgrade as soon as possible. You won't get any support for older versions. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: hot-backup.py
Hi Mark, I am not running a server right now. Our repository is on another computer and I access it through a network mapped drive. Thanks, Kamran -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Wednesday, February 22, 2012 9:57 AM To: Salari, Kamran Cc: users@subversion.apache.org Subject: Re: hot-backup.py On Tue, Feb 21, 2012 at 7:27 PM, Salari, Kamran kamran.sal...@philips.com wrote: I am new to Subversion, and I am using TortoiseSVN-1.7.3 and Slik-Subversion-1.7.2 on my XP system (Service Pack 3). I would like to know if there is a Windows version of hot-backup.py which I can use. It appears the script in tools\backup is written for a Unix environment. You might want to consider installing and running Subversion Edge on your server: http://www.open.collab.net/products/subversion/SVNedge.html It provides a web based UI for managing your repositories and one of the features it provides is scheduled backups. So you can schedule a hot copy backup to run hourly/daily as well as how many versions to keep. Then you do not have to mess around with scripts and Windows task schedulers. -- Thanks Mark Phippard http://markphip.blogspot.com/ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Re: hot-backup.py
On Feb 22, 2012, at 11:56, Salari, Kamran wrote: I am not running a server right now. Our repository is on another computer and I access it through a network mapped drive. Please stop doing that immediately and set up a proper server.
Re: Subversion restore
On Wed, Feb 22, 2012 at 11:52 AM, svenk1 bob.tro...@ketchum.com wrote: Les - It is an older Centos 4.8 install. I ran yum install subversion and copied the repository directory to the new server. I tried the import because I didnt have dumps. I don't know what I am doing. I tried the dump but got the same message svnadmin dump /svn svn: Expected version '3' of repository; found version '5' Dave - I just installed subversion by running yum install subversion on this older centos 4.8 install. Is there a way I can tell what version the repository is? I would prefer to install the same version to avoid conflicts with the older OS. CentOS 4.x is _extremely_ old. For some things, stability is a good thing, but with subversion newer is better. And apparently someone had installed a newer version of subversion on the old box, which is causing part of your problem now (although it would not have been a good thing for your 'import' command to have worked either).Unless you have other apps that have to stay on 4.8, I'd recommend installing Centos 6.2 at this point which should come with a usable 1.6 version of subversion. If you have to stay on 4.8, look at Rpmforge or other 3rd party yum package repositories for a more current subversion to match what you had been running. Once you install a subversion that is at least as new as the one that created the repository it should be able to use it directly, but I'd probably still go through the motions of the dump/load to give it a chance to use the most efficient format. -- Les Mikesell lesmikes...@gmail.com
Re: commit hooks - is there a hook which is called after commit even if its not successful
Am 22.02.2012 18:27, schrieb Ryan Schmidt: On Feb 22, 2012, at 09:23, Torsten Krah wrote: the http://svnbook.red-bean.com/en/1.6/svn.ref.reposhooks.html book tells about the various post-* hooks. But those one are called on successfull operations. Whats the way to implement a hook, which is called after commit - it does not matter if successful or failed - the hook must be able to figure out if all went fine or something went wrong. Can this be done or is this not possible at the moment? I don't think this is possible. You have the pre-commit hook, which fires before the commit; you can examine the commit and reject it at that time if desired. Assuming you don't reject it, the commit goes to Subversion's engine which writes it to the repository. Then it calls the post-commit hook, where you can do additional operations like send email notifications about the commit. What circumstance to you envision in which the commit is not successful, and what automated action do you intend to perform as a result? If commit can not fail - for which ever reason - why the doc does state that the hook does only run if the commit is actual successful? So it is possible to fail or not? I need to be sure that prepared external resources from pre-commit are cleaned up - even in case it did fail. If it would be run only on success, which does imply that it might fail, i am unable to clean up my work done in pre-commit. any other ideas how to do? smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: commit hooks - is there a hook which is called after commit even if its not successful
On Wed, Feb 22, 2012 at 14:49, Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de wrote: Am 22.02.2012 18:27, schrieb Ryan Schmidt: On Feb 22, 2012, at 09:23, Torsten Krah wrote: the http://svnbook.red-bean.com/en/1.6/svn.ref.reposhooks.html book tells about the various post-* hooks. But those one are called on successfull operations. Whats the way to implement a hook, which is called after commit - it does not matter if successful or failed - the hook must be able to figure out if all went fine or something went wrong. Can this be done or is this not possible at the moment? I don't think this is possible. You have the pre-commit hook, which fires before the commit; you can examine the commit and reject it at that time if desired. Assuming you don't reject it, the commit goes to Subversion's engine which writes it to the repository. Then it calls the post-commit hook, where you can do additional operations like send email notifications about the commit. What circumstance to you envision in which the commit is not successful, and what automated action do you intend to perform as a result? If commit can not fail - for which ever reason - why the doc does state that the hook does only run if the commit is actual successful? So it is possible to fail or not? I need to be sure that prepared external resources from pre-commit are cleaned up - even in case it did fail. If it would be run only on success, which does imply that it might fail, i am unable to clean up my work done in pre-commit. any other ideas how to do? Can pre-commit clean up after itself, so that the environment is clean regardless of the result of the commit? Perhaps if you described in more detail what you mean when you say prepared external resources from pre-commit people can provide more complete guidance.
Re: commit hooks - is there a hook which is called after commit even if its not successful
On Wed, Feb 22, 2012 at 2:49 PM, Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de wrote: If commit can not fail - for which ever reason - why the doc does state that the hook does only run if the commit is actual successful? So it is possible to fail or not? Commits can fail. A common reason would be that a file included in the commit was not at the HEAD revision in your working copy. I believe these sort of checks do not happen until after the pre-commit hook is called. I need to be sure that prepared external resources from pre-commit are cleaned up - even in case it did fail. If it would be run only on success, which does imply that it might fail, i am unable to clean up my work done in pre-commit. any other ideas how to do? There is no hook called if the commit fails. If you want to clean something up that you created during your pre-commit hook then write a background job that checks for stale information and cleans them up. Without a lot more details about what you are doing in your pre-commit hook I do not think there are any other suggestions that can be made. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: commit hooks - is there a hook which is called after commit even if its not successful
Mark Phippard markp...@gmail.com writes: On Wed, Feb 22, 2012 at 2:49 PM, Torsten Krah tk...@fachschaft.imn.htwk-leipzig.de wrote: If commit can not fail - for which ever reason - why the doc does state that the hook does only run if the commit is actual successful? So it is possible to fail or not? Commits can fail. A common reason would be that a file included in the commit was not at the HEAD revision in your working copy. I believe these sort of checks do not happen until after the pre-commit hook is called. Out-of-date checks happen twice. They happen first at an early stage during the commit as this allows us to reject the commit before the user has spent a lot of time uploading content. However these early out-of-date checks could themselves be out-of-date by the time we come to finalise the commit (another commit could have completed). So the out-of-date checks get repeated once Subversion has taken the commit lock, and this second check is after the pre-commit hook has run. -- Philip
SVN commit behaviour not consistent with other commands (such as delete or add)
Hi, This may or may not be an issue, since it could be how the OS interprets the command. Explanation as follows. Discovered an issue with running svn commit: Merge is successful [evanw@laptop] /Users/evanw/misc/rd/ = svn merge http://svn/repo/tools/release_dashboard/trunk --dry-run --- Merging r61477 through r61658 into '.': Djira.project.class.php Dsituationreport.class.php Dreport.class.php Dsituationreport.stage.class.php Djira.project.checkpoint.class.php Dindex.php Djira.class.php [evanw@laptop] /Users/evanw/misc/rd/ = svn merge http://svn/repo/tools/release_dashboard/trunk --- Merging r61477 through r61658 into '.': Djira.project.class.php Dreport.class.php Dsituationreport.class.php Dsituationreport.stage.class.php Djira.project.checkpoint.class.php Dindex.php Djira.class.php However, committing with * does not work: [evanw@laptop] /Users/evanw/misc/rd/ = svn ci * -m 'BM-123: merge from trunk into my branch' Committing with . or the main directory name will work: [evanw@laptop] /Users/evanw/misc/rd/ = svn ci . -m 'BM-123: merge from trunk into my branch' Sending. Deleting index.php Deleting jira.class.php Deleting jira.project.checkpoint.class.php Deleting jira.project.class.php Deleting report.class.php Deleting situationreport.class.php Deleting situationreport.stage.class.php Committed revision 61659. Strangely, other commands with * used will work, such as svn delete, svn add, etc. Even svn commit * will work somewhat as it commits the modified and added files, but not the deleted ones. I had a discussion with others and their explanation is that the character * refers to valid targets and thus deleted items are not targettable, hence their being missed in the commit. Should this be a valid exception case for svn commit so as to make it consistent with other svn commands? Is this Evan Wee [Build] Email/AIM: ev...@nationalfibre.net
Re: SVN commit behaviour not consistent with other commands (such as delete or add)
2012/2/23 Evan Wee ev...@nationalfibre.net: Strangely, other commands with * used will work, such as svn delete, svn add, etc. Even svn commit * will work somewhat as it commits the modified and added files, but not the deleted ones. I had a discussion with others and their explanation is that the character * refers to valid targets and thus deleted items are not targettable, hence their being missed in the commit. Should this be a valid exception case for svn commit so as to make it consistent with other svn commands? The '*' filename pattern on Unixes is processed by the Shell before the command is passed to Subversion. It matches only existing files. Subversion cannot do anything with it. Officially - see http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html Shell Command Language - 2.6.6 Pathname Expansion Best regards, Konstantin Kolinko
Re: SVN commit behaviour not consistent with other commands (such as delete or add)
On 02/22/2012 02:20 PM, Konstantin Kolinko wrote: 2012/2/23 Evan Weeev...@nationalfibre.net: Strangely, other commands with * used will work, such as svn delete, svn add, etc. Even svn commit * will work somewhat as it commits the modified and added files, but not the deleted ones. I had a discussion with others and their explanation is that the character * refers to valid targets and thus deleted items are not targettable, hence their being missed in the commit. Should this be a valid exception case for svn commit so as to make it consistent with other svn commands? The '*' filename pattern on Unixes is processed by the Shell before the command is passed to Subversion. It matches only existing files. Subversion cannot do anything with it. Officially - see http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html Shell Command Language - 2.6.6 Pathname Expansion And even if this could be changed, you should just get in the practice of using . as a target instead, as if you do a merge and then 'svn commit *', you won't pick up the property change on the current working directory. In other words, you would have committed everything but the metadata to record the merge. Blair
Re: SVN commit behaviour not consistent with other commands (such as delete or add)
On Feb 22, 2012, at 16:10, Evan Wee wrote: However, committing with * does not work: The asterisk is interpreted by your shell; Subversion has no opportunity to see that you typed an asterisk.
