Hmm. A quick glance at subversion/bindings/swig/svn_wc.i tells me that
perhaps svn_wc_status_func2_t aren't supported by the Perl bindings?
(notice the pattern of #ifndef's around svn_wc_status_func_t and
svn_wc_status_func2_t)
Jim Searle wrote on Fri, Apr 20, 2012 at 14:21:52 -0700:
> I was able
I was able to get info2 working with Daniel's suggestion, but now I
can not get status3 to work.
For the code below I get this error when it tries to run status3:
TypeError in method 'svn_client_status3', argument 4 of type
'svn_wc_status_func2_t'
Seems like it wants me to typecast the subroutine
Stefan Sperling wrote on Fri, Apr 20, 2012 at 14:38:19 +0200:
> Such problems didn't happen during the 1.6->1.7 timeframe as far as I
> can see (people got an error message and understood what was going on).
>
But in the 1.6->1.7 upgrade people had to go through all working copies
managed by unma
Hi,
If having an SVN 1.7 working copy which was deleted from the repository,
svn status -u
does not report any remote change, unless using
svn status -u -v
Is this OK? I would expect to report that there are remote changes. This
was the behavior in SVN 1.6.
Regards,
Florin Avram
On Fri, Apr 20, 2012 at 2:57 PM, Stefan Sperling wrote:
> On Fri, Apr 20, 2012 at 02:38:19PM +0200, Stefan Sperling wrote:
>> On Fri, Apr 20, 2012 at 01:16:24PM +0100, Philip Martin wrote:
>> > Note that when status acquires the lock it has to repeat the timestamp
>> > check, it cannot be assumed
Daniel Shahaf writes:
> Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 14:05:17 +0700:
>> I think that the following sequence should be used:
>> 1) /etc/subversion
>> 2) --config-dir (if set)
>> 3) $XDG_CONFIG_HOME/subversion (if XDG_CONFIG_HOME set and not empty)
>> 4) $HOME/.subversion
>
> Not qui
On Fri, Apr 20, 2012 at 02:38:19PM +0200, Stefan Sperling wrote:
> On Fri, Apr 20, 2012 at 01:16:24PM +0100, Philip Martin wrote:
> > Note that when status acquires the lock it has to repeat the timestamp
> > check, it cannot be assumed that the timestamp is still broken, or that
> > the file still
On Fri, Apr 20, 2012 at 01:16:24PM +0100, Philip Martin wrote:
> Stefan Sperling writes:
>
> > You're not arguing about inter-client effects, right? I.e. a GUI
> > client trying to update its icons while a command line client 'svn
> > status' run is updating timestamps? This situation isn't much
On 04/20/2012 01:06 PM, Stefan Sperling wrote:
On Fri, Apr 20, 2012 at 12:39:33PM +0200, Florent Guiliani wrote:
Just got this with subversion 1.7.4:
$ svn diff -r BASE:HEAD ^/trunk
svn: E235000: In file
'/build/buildd/subversion-1.7.4/subversion/libsvn_client/diff.c'
line 1937: assertion faile
Stefan Sperling writes:
> You're not arguing about inter-client effects, right? I.e. a GUI
> client trying to update its icons while a command line client 'svn
> status' run is updating timestamps? This situation isn't much different
> to a command line client performing a concurrent update or co
On Fri, Apr 20, 2012 at 07:06:08AM -0400, Nico Kadel-Garcia wrote:
> I note that there is no libserf or serf RPM published, anywhere, for RHEL,
> and it's not yet enabled for Fedora. That makes the serf libraries a bit
> more awkward to integrate for testing. How much benefit is there in using
> s
On Fri, Apr 20, 2012 at 11:59:32AM +0100, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Of course, this would require 'svn status' to obtain a write lock on wc.db.
> > The status operation must not hold a write lock during regular operation
> > because doing so prevents concurrent read acc
I note that there is no libserf or serf RPM published, anywhere, for RHEL,
and it's not yet enabled for Fedora. That makes the serf libraries a bit
more awkward to integrate for testing. How much benefit is there in using
serf rether than neon for subversion-1.7.x? I'm developing a sneaking
suspic
On Fri, Apr 20, 2012 at 12:39:33PM +0200, Florent Guiliani wrote:
> Just got this with subversion 1.7.4:
>
> $ svn diff -r BASE:HEAD ^/trunk
> svn: E235000: In file
> '/build/buildd/subversion-1.7.4/subversion/libsvn_client/diff.c'
> line 1937: assertion failed (! svn_path_is_url(path2))
> Aborted
Florent Guiliani writes:
> Just got this with subversion 1.7.4:
>
> $ svn diff -r BASE:HEAD ^/trunk
> svn: E235000: In file
> /build/buildd/subversion-1.7.4/subversion/libsvn_client/diff.c' line
> 1937: assertion failed (! svn_path_is_url(path2))
> Aborted
Happens with Subversion trunk as well:
Stefan Sperling writes:
> Of course, this would require 'svn status' to obtain a write lock on wc.db.
> The status operation must not hold a write lock during regular operation
> because doing so prevents concurrent read access by other clients.
> To keep the time window where the write lock is h
Just got this with subversion 1.7.4:
$ svn diff -r BASE:HEAD ^/trunk
svn: E235000: In file
'/build/buildd/subversion-1.7.4/subversion/libsvn_client/diff.c' line
1937: assertion failed (! svn_path_is_url(path2))
Aborted
Enjoy,
--
Florent Guiliani
On Fri, Apr 20, 2012 at 11:16:27AM +0100, Philip Martin wrote:
> Johan Corveleyn writes:
>
> > Now, all is not lost if there are mismatches: 'svn cleanup' corrects
> > the last-mod-times in the wc-metadata (for all files which are still
> > identical to the pristine, the last-mod-time in metadata
Johan Corveleyn writes:
> Now, all is not lost if there are mismatches: 'svn cleanup' corrects
> the last-mod-times in the wc-metadata (for all files which are still
> identical to the pristine, the last-mod-time in metadata will be
> updated). But the problem is that users are lazy, and they won
Hi all,
As some of you may know, SVN uses filesize and last-mod-time of files
to optimize 'svn status' and other commands (if filesize and
last-mod-time of the file match those in the wc-metadata, the file is
assumed to be unchanged, and doesn't have to be read --- only if these
don't match, the f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20.04.2012 14:28, Daniel Shahaf wrote:
>>> the default lookup order of config from: /etc/subversion,
>>> $HOME/.subversion (as modified by --config-dir) to some other
>>> sequence of directories, obtained from $XDG_* envvars?
>> I think that the
Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 14:05:17 +0700:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 20.04.2012 1:35, Daniel Shahaf wrote:
> > Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 00:32:40 +0700:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >> On 04/19/2012 11:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20.04.2012 1:35, Daniel Shahaf wrote:
> Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 00:32:40 +0700:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 04/19/2012 11:32 PM, Daniel Shahaf wrote:
>>> For what configuration and what data? Clien
23 matches
Mail list logo
