Proper source/way to integration Subversion for Win32 app and MacOSX
Hi guys, I have been googling and couldn't seem to find anything that demonstrate how does one obtain the subversion api required to provide subversion integration in one's software. So far I have go things up and running for windows by locating myself a copy of precompiled libs and headers for Win32. On windows, I did manage to find a precompiled libs and headers for apache portable runtime (it comes with the precompiled subversion api libs and headers). However, on the Mac, I can't seem to find anything similar that includes the apache libs and header. So just wonder what is the recommended approach for getting libs and headers? Is there a source that provides me with the libs and headers that I can know for certain is going to work with the subversion libs and headers? Thuan PS: I am not subscribed to the mailing list and would appreciate if you could CC me the replies. Thanks.
repeated calls to svn_client_status5 seems to hang
Hi all, I have yet another question about subversion if people don't mind. I have been using svn_client_status5 to get the status of the file after each action (i.e. revert, delete, add, etc) it seems to work fine most of the time. However, if I were to set the update flag (i.e. to contact repository about status), the call appears to hang and not return after several repeated calls. Setting the flag to false would work, but I am just curious to know if subversion implements some kind of guard against repeated polling of status to guard against hacking and stuff which could have resulted in the hang instead of returning a non null error. Thuan PS: I am not subscribed to the mailing list, so would appreciated if replies are cc to my email address. Thanks.
RE: Status after svn_client_move6
Thanks for all the replies. Looks like my best bet would be to do the status check at a later stage and revert if necessary. Thuan -Original Message- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Thursday, June 07, 2012 7:28 PM To: 'Stefan Sperling'; 'Thuan Seah Tan' Cc: users@subversion.apache.org Subject: RE: Status after svn_client_move6 > -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 7 juni 2012 10:46 > To: Thuan Seah Tan > Cc: users@subversion.apache.org > Subject: Re: Status after svn_client_move6 > > On Thu, Jun 07, 2012 at 05:08:40PM +1000, Thuan Seah Tan wrote: > > Hi all, > > > > > > > > I am new to subversion and subversion api, and I have a question > > which I hope someone can point me in the right direction. I am > > trying to do a subversion integration in the tool I am working on, > > and to rename a file, I > > believe I need to call the svn_client_move6 function. That's all > > good, I can > > see the file is being renamed in Windows Explorer after the call. > > What puzzles me is the svn_client_status5 call straight after. If I > > have an unmodified file A.txt, renaming it to B.txt and back to > > A.txt should give me > > the node status as "replaced" but text status should remain > > "normal". I > have > > TortoiseSVN installed, and using the file properties dialog, I can > > see that > > the file goes into "replaced" and "normal" state. But trying to call > > svn_client_status5 straight after the svn_client_move6 returns the > > file as > > "replaced" and "modified" in the status5 callback. It is only on subsequent > > call to svn_client_status5 (after some arbitrary time) the status is > > correctly marked as "replaced" and "normal". Wondering is there > something I > > am doing wrong? This is how I am calling svn_client_status5: > > The second move creates a new file A.txt with a new modification > timestamp. > > To avoid full content comparison, 'svn status' reports a file as > modified if the pristine file's modification timestamp and size differ > from the working file's timestamp and size. > Else, it compares file content to determine whether a file was modified. > > There are also cases where the cached timestamp becomes invalid, the > full content is compared regardless of timestamp differences, and the > cached timestamp is then corrected. I believe this is why you're > seeing the node status flip from modified to normal. > > For details, take a look at the function svn_wc__internal_file_modified_p() > in libsvn_wc/questions.c. If you set appropriate debugger breakpoints > in there you should be able to observe the code paths taken when the > file is reported as modified vs. when the file is reported as unmodified. > > Note also that Subversion sometimes sleeps deliberately to wait for > on-disk timestamp updates. See svn_io_sleep_for_timestamps(). What you might see is that the file is somehow still blocked for reading when you are calling status on it. If the timestamps don't match (see anser Stefan), then a compare is performed. But if the file is (temporarily) not readable, because some other process blocks that the file is marked as 'modified'. This other process could be a file indexer, a virusscanner, a disk status monitor, etc. What you see later is probably that the file was closed and the status succeeds again. Bert
When connecting to an https server force use of TLS or SSLv3?
When svn attempts to connect to an https URL, the underlying protocol library (openssl?) attempts to start the secure protocol negotiation at the most basic level, plain SSL. Unfortunately, I have to connect to a server that requires SSL3 or TLS1, and refuses to respond to SSL or SSL2. I've done some troubleshooting using s_client and confirmed that if I let s_client start with the default protocol the server never responds to the CLIENT HELLO: $ openssl s_client -connect server.domain.com:443 CONNECTED(0003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 320 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Watching this in Wireshark I see: ClientServer ---syn--> <--ack--- ---CLIENT HELLO-> <--ack--- [60 second pause] <--rst--- If I tell s_client to use ssl2 the server immediately closes the connection. Only ssl3 and tls1 work. Is there any way to tell subversion to tell the underlying ssl libraries to skip SSL and SSL2, and start the negotiation with TLS or SSL3? I've looked for an OpenSSL config file, but that seems to control only certificate generation.
RE: svnversion feature
> I am in the process of putting together make files for firmware builds and run > into an issue that I didn't see addressed in any of the issues lists. One of > the > things I want to do is to tag the SVN revision that a binary was built from > onto > the file name (this was actually requested by manufacturing and I agree with > their view point). The revision is easy enough to get from svnversion. The > problem is, that when I run it in my working directory, inevitably I get a > mixed revision result, even if I have just committed (something like 3:26). > While this may be informative to me as a developer, this is not something I > can embed in a file name. At the same time Make has no ability to extract > just the part after the colon. > > I see three solutions to this problem: > 1. create another directory and do a clean checkout of the version I just > committed. I tried this and it works well. Cumbersome though. > 2. implement an external tool that runs svnversion and then disassembles > the result to get the correct number for use in a file name. Ugly, too many > tools needed already to get every day work done. > 3. implement an option in svnversion that makes it to only spit out the > highest revision number (no colon). Alternatively, the colon could be > replaced by any character the user likes. That way something compatible > with the file system can be chosen. I guess what I meant to say is, it would > be > nice to have control over the format in which svnversion reports the version. > Thanks for taking the time to read and form an opinion about this. 4. Don't build against a mixed revision? Run svn up prior to doing your build, or as the first step. BOb
Re: svnversion feature
On 6/7/2012 9:27 AM, Elmar Grom wrote: Hi, I am in the process of putting together make files for firmware builds and run into an issue that I didn't see addressed in any of the issues lists. One of the things I want to do is to tag the SVN revision that a binary was built from onto the file name (this was actually requested by manufacturing and I agree with their view point). The revision is easy enough to get from svnversion. The problem is, that when I run it in my working directory, inevitably I get a mixed revision result, even if I have just committed (something like 3:26). While this may be informative to me as a developer, this is not something I can embed in a file name. At the same time Make has no ability to extract just the part after the colon. I see three solutions to this problem: 1. create another directory and do a clean checkout of the version I just committed. I tried this and it works well. Cumbersome though. 2. implement an external tool that runs svnversion and then disassembles the result to get the correct number for use in a file name. Ugly, too many tools needed already to get every day work done. 3. implement an option in svnversion that makes it to only spit out the highest revision number (no colon). Alternatively, the colon could be replaced by any character the user likes. That way something compatible with the file system can be chosen. I guess what I meant to say is, it would be nice to have control over the /format/ in which svnversion reports the version. Thanks for taking the time to read and form an opinion about this. Elmar Rather than a clean checkout; you can run "svn update" in the root directory of your working copy. The colon says you have a "mixed revision" working copy, meaning that parts of it represent an earlier state of the repository. This is not what you want. An update assures all commits by you or other developers are incorporated in your build. You should not trim off the lower revision number, because it is telling you something: the binary you just built cannot be reproduced directly later. You would somehow have to rebuild the on-disk state your working copy. That is not the point of a revision control system! A freshly checked out working directory has the advantage of ensuring that there are no local changes to files that would also prevent exact reproduction of the build. What you choose is up to you, but exact reproduction is the goal. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
svnversion feature
Hi, I am in the process of putting together make files for firmware builds and run into an issue that I didn't see addressed in any of the issues lists. One of the things I want to do is to tag the SVN revision that a binary was built from onto the file name (this was actually requested by manufacturing and I agree with their view point). The revision is easy enough to get from svnversion. The problem is, that when I run it in my working directory, inevitably I get a mixed revision result, even if I have just committed (something like 3:26). While this may be informative to me as a developer, this is not something I can embed in a file name. At the same time Make has no ability to extract just the part after the colon. I see three solutions to this problem: 1. create another directory and do a clean checkout of the version I just committed. I tried this and it works well. Cumbersome though. 2. implement an external tool that runs svnversion and then disassembles the result to get the correct number for use in a file name. Ugly, too many tools needed already to get every day work done. 3. implement an option in svnversion that makes it to only spit out the highest revision number (no colon). Alternatively, the colon could be replaced by any character the user likes. That way something compatible with the file system can be chosen. I guess what I meant to say is, it would be nice to have control over the format in which svnversion reports the version. Thanks for taking the time to read and form an opinion about this. Elmar
Re: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
On 2012-06-07 11:47, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Bert Huijben [mailto:b...@qqmail.nl]
>> Sent: donderdag 7 juni 2012 11:34
>> To: 'Daniel Widenfalk'; d...@subversion.apache.org;
>> users@subversion.apache.org
>> Subject: RE: Potential issue in
> libsvn_diff:diff_file.c:find_identical_prefix
>>
>>
>>
>>> -Original Message-
>>> From: Daniel Widenfalk [mailto:daniel.widenf...@iar.se]
>>> Sent: donderdag 7 juni 2012 11:06
>>> To: d...@subversion.apache.org; users@subversion.apache.org
>>> Subject: Potential issue in
> libsvn_diff:diff_file.c:find_identical_prefix
>>>
>>> Hi,
>>>
>>> First off: I'm sorry if I post this in the wrong way.
>>>
>>> I've found a potential issue in the function "find_identical_prefix"
>>> in libsvn_diff/diff_file.c
>>>
>>> The faulty code looks like this:
>>>
>>> diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
>>> ---
>>> is_match = TRUE;
>>> for (delta = 0; delta < max_delta && is_match; delta +=
>>> sizeof(apr_uintptr_t))
>>> {
>>> apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp +
>> delta);
>>> if (contains_eol(chunk))
>>> break;
>>>
>>> for (i = 1; i < file_len; i++)
>>> if (chunk != *(const apr_size_t *)(file[i].curp + delta))
>>> {
>>> is_match = FALSE;
>>> delta -= sizeof(apr_size_t);
>>> break;
>>> }
>>> }
>>> ---
>>>
>>> The problem is that the 64-bit build I'm using (ColabNet) have
>>> different sizes for apr_uintptr_t and apr_size_t.
>>>
>>> From looking at the disassembly I can deduce that
>>> sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
>>> to these two issues:
>>>
>>> 1) Data is truncated in the initial read-up to "chunk" and the compare
>>>in the inner loop will fail because the second read-up will compare
>>>a 64-bit value against a 32-bit value.
>>>
>>> 2) When the test fails it will back up delta by 8, not 4, resulting in
>>>a buffer advance of -4 later in the code. Once the search code has
>>>advanced another 4 character if will be back at the same spot.
>>>
>>>Rinse and repeat.
>>>
>>> Are these a known issues?
>>>
>>> In my case this results in an infinite loop on the following input
>>> string:
>>>
>>> 23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
>>>
>>> I found this out when my svn-client spiraled into an infinite loop
>>> and would not respond to ctrl-c during a "svn up" command.
>>
>> Which apr version did you use?
>>
>> I think this issue was fixed in Subversion 1.7.2:
>>
>> (From http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES)
>> * properly define WIN64 on Windows x64 builds (r1188609)
>>
>> Not by a code change here in this piece of the code, but by making sure
> that
>> the pointer size is defined correctly in apr.
>> So that would fix this issue and maybe several others.
>
> And since then then also APR was patched to properly check for _WIN64
> instead of WIN64 for defining these variable types correctly.
Updating to 1.7.5 makes the issue go away. The type mismatch is still
in the 1.7.5 source but if the system do guarantee that
sizeof(apr_uintptr_t) == sizeof(apr_size_t)
then it should be ok.
I did try to look in the libsvn_diff bug tracker before posting but
didn't see anything there. Looking at build issues didn't occur to
me, even though it should have been obvious from the error.
Regards
/Daniel Widenfalk
RE: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 7 juni 2012 11:34
> To: 'Daniel Widenfalk'; d...@subversion.apache.org;
> users@subversion.apache.org
> Subject: RE: Potential issue in
libsvn_diff:diff_file.c:find_identical_prefix
>
>
>
> > -Original Message-
> > From: Daniel Widenfalk [mailto:daniel.widenf...@iar.se]
> > Sent: donderdag 7 juni 2012 11:06
> > To: d...@subversion.apache.org; users@subversion.apache.org
> > Subject: Potential issue in
libsvn_diff:diff_file.c:find_identical_prefix
> >
> > Hi,
> >
> > First off: I'm sorry if I post this in the wrong way.
> >
> > I've found a potential issue in the function "find_identical_prefix"
> > in libsvn_diff/diff_file.c
> >
> > The faulty code looks like this:
> >
> > diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
> > ---
> > is_match = TRUE;
> > for (delta = 0; delta < max_delta && is_match; delta +=
> > sizeof(apr_uintptr_t))
> > {
> > apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp +
> delta);
> > if (contains_eol(chunk))
> > break;
> >
> > for (i = 1; i < file_len; i++)
> > if (chunk != *(const apr_size_t *)(file[i].curp + delta))
> > {
> > is_match = FALSE;
> > delta -= sizeof(apr_size_t);
> > break;
> > }
> > }
> > ---
> >
> > The problem is that the 64-bit build I'm using (ColabNet) have
> > different sizes for apr_uintptr_t and apr_size_t.
> >
> > From looking at the disassembly I can deduce that
> > sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
> > to these two issues:
> >
> > 1) Data is truncated in the initial read-up to "chunk" and the compare
> >in the inner loop will fail because the second read-up will compare
> >a 64-bit value against a 32-bit value.
> >
> > 2) When the test fails it will back up delta by 8, not 4, resulting in
> >a buffer advance of -4 later in the code. Once the search code has
> >advanced another 4 character if will be back at the same spot.
> >
> >Rinse and repeat.
> >
> > Are these a known issues?
> >
> > In my case this results in an infinite loop on the following input
> > string:
> >
> > 23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
> >
> > I found this out when my svn-client spiraled into an infinite loop
> > and would not respond to ctrl-c during a "svn up" command.
>
> Which apr version did you use?
>
> I think this issue was fixed in Subversion 1.7.2:
>
> (From http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES)
> * properly define WIN64 on Windows x64 builds (r1188609)
>
> Not by a code change here in this piece of the code, but by making sure
that
> the pointer size is defined correctly in apr.
> So that would fix this issue and maybe several others.
And since then then also APR was patched to properly check for _WIN64
instead of WIN64 for defining these variable types correctly.
Bert
>
> Bert
>
RE: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
> -Original Message-
> From: Daniel Widenfalk [mailto:daniel.widenf...@iar.se]
> Sent: donderdag 7 juni 2012 11:06
> To: d...@subversion.apache.org; users@subversion.apache.org
> Subject: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
>
> Hi,
>
> First off: I'm sorry if I post this in the wrong way.
>
> I've found a potential issue in the function "find_identical_prefix"
> in libsvn_diff/diff_file.c
>
> The faulty code looks like this:
>
> diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
> ---
> is_match = TRUE;
> for (delta = 0; delta < max_delta && is_match; delta +=
> sizeof(apr_uintptr_t))
> {
> apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp +
delta);
> if (contains_eol(chunk))
> break;
>
> for (i = 1; i < file_len; i++)
> if (chunk != *(const apr_size_t *)(file[i].curp + delta))
> {
> is_match = FALSE;
> delta -= sizeof(apr_size_t);
> break;
> }
> }
> ---
>
> The problem is that the 64-bit build I'm using (ColabNet) have
> different sizes for apr_uintptr_t and apr_size_t.
>
> From looking at the disassembly I can deduce that
> sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
> to these two issues:
>
> 1) Data is truncated in the initial read-up to "chunk" and the compare
>in the inner loop will fail because the second read-up will compare
>a 64-bit value against a 32-bit value.
>
> 2) When the test fails it will back up delta by 8, not 4, resulting in
>a buffer advance of -4 later in the code. Once the search code has
>advanced another 4 character if will be back at the same spot.
>
>Rinse and repeat.
>
> Are these a known issues?
>
> In my case this results in an infinite loop on the following input
> string:
>
> 23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
>
> I found this out when my svn-client spiraled into an infinite loop
> and would not respond to ctrl-c during a "svn up" command.
Which apr version did you use?
I think this issue was fixed in Subversion 1.7.2:
(From http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES)
* properly define WIN64 on Windows x64 builds (r1188609)
Not by a code change here in this piece of the code, but by making sure that
the pointer size is defined correctly in apr.
So that would fix this issue and maybe several others.
Bert
RE: Status after svn_client_move6
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 7 juni 2012 10:46 > To: Thuan Seah Tan > Cc: users@subversion.apache.org > Subject: Re: Status after svn_client_move6 > > On Thu, Jun 07, 2012 at 05:08:40PM +1000, Thuan Seah Tan wrote: > > Hi all, > > > > > > > > I am new to subversion and subversion api, and I have a question which I > > hope someone can point me in the right direction. I am trying to do a > > subversion integration in the tool I am working on, and to rename a file, I > > believe I need to call the svn_client_move6 function. That's all good, I can > > see the file is being renamed in Windows Explorer after the call. What > > puzzles me is the svn_client_status5 call straight after. If I have an > > unmodified file A.txt, renaming it to B.txt and back to A.txt should give me > > the node status as "replaced" but text status should remain "normal". I > have > > TortoiseSVN installed, and using the file properties dialog, I can see that > > the file goes into "replaced" and "normal" state. But trying to call > > svn_client_status5 straight after the svn_client_move6 returns the file as > > "replaced" and "modified" in the status5 callback. It is only on subsequent > > call to svn_client_status5 (after some arbitrary time) the status is > > correctly marked as "replaced" and "normal". Wondering is there > something I > > am doing wrong? This is how I am calling svn_client_status5: > > The second move creates a new file A.txt with a new modification > timestamp. > > To avoid full content comparison, 'svn status' reports a file as modified > if the pristine file's modification timestamp and size differ from the > working file's timestamp and size. > Else, it compares file content to determine whether a file was modified. > > There are also cases where the cached timestamp becomes invalid, the > full content is compared regardless of timestamp differences, and the > cached timestamp is then corrected. I believe this is why you're seeing > the node status flip from modified to normal. > > For details, take a look at the function svn_wc__internal_file_modified_p() > in libsvn_wc/questions.c. If you set appropriate debugger breakpoints in > there you should be able to observe the code paths taken when the file is > reported as modified vs. when the file is reported as unmodified. > > Note also that Subversion sometimes sleeps deliberately to wait for > on-disk timestamp updates. See svn_io_sleep_for_timestamps(). What you might see is that the file is somehow still blocked for reading when you are calling status on it. If the timestamps don't match (see anser Stefan), then a compare is performed. But if the file is (temporarily) not readable, because some other process blocks that the file is marked as 'modified'. This other process could be a file indexer, a virusscanner, a disk status monitor, etc. What you see later is probably that the file was closed and the status succeeds again. Bert
Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
Hi,
First off: I'm sorry if I post this in the wrong way.
I've found a potential issue in the function "find_identical_prefix"
in libsvn_diff/diff_file.c
The faulty code looks like this:
diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
---
is_match = TRUE;
for (delta = 0; delta < max_delta && is_match; delta +=
sizeof(apr_uintptr_t))
{
apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp + delta);
if (contains_eol(chunk))
break;
for (i = 1; i < file_len; i++)
if (chunk != *(const apr_size_t *)(file[i].curp + delta))
{
is_match = FALSE;
delta -= sizeof(apr_size_t);
break;
}
}
---
The problem is that the 64-bit build I'm using (ColabNet) have
different sizes for apr_uintptr_t and apr_size_t.
>From looking at the disassembly I can deduce that
sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
to these two issues:
1) Data is truncated in the initial read-up to "chunk" and the compare
in the inner loop will fail because the second read-up will compare
a 64-bit value against a 32-bit value.
2) When the test fails it will back up delta by 8, not 4, resulting in
a buffer advance of -4 later in the code. Once the search code has
advanced another 4 character if will be back at the same spot.
Rinse and repeat.
Are these a known issues?
In my case this results in an infinite loop on the following input
string:
23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
I found this out when my svn-client spiraled into an infinite loop
and would not respond to ctrl-c during a "svn up" command.
Regards
/Daniel Widenfalk
Re: Status after svn_client_move6
On Thu, Jun 07, 2012 at 05:08:40PM +1000, Thuan Seah Tan wrote: > Hi all, > > > > I am new to subversion and subversion api, and I have a question which I > hope someone can point me in the right direction. I am trying to do a > subversion integration in the tool I am working on, and to rename a file, I > believe I need to call the svn_client_move6 function. That's all good, I can > see the file is being renamed in Windows Explorer after the call. What > puzzles me is the svn_client_status5 call straight after. If I have an > unmodified file A.txt, renaming it to B.txt and back to A.txt should give me > the node status as "replaced" but text status should remain "normal". I have > TortoiseSVN installed, and using the file properties dialog, I can see that > the file goes into "replaced" and "normal" state. But trying to call > svn_client_status5 straight after the svn_client_move6 returns the file as > "replaced" and "modified" in the status5 callback. It is only on subsequent > call to svn_client_status5 (after some arbitrary time) the status is > correctly marked as "replaced" and "normal". Wondering is there something I > am doing wrong? This is how I am calling svn_client_status5: The second move creates a new file A.txt with a new modification timestamp. To avoid full content comparison, 'svn status' reports a file as modified if the pristine file's modification timestamp and size differ from the working file's timestamp and size. Else, it compares file content to determine whether a file was modified. There are also cases where the cached timestamp becomes invalid, the full content is compared regardless of timestamp differences, and the cached timestamp is then corrected. I believe this is why you're seeing the node status flip from modified to normal. For details, take a look at the function svn_wc__internal_file_modified_p() in libsvn_wc/questions.c. If you set appropriate debugger breakpoints in there you should be able to observe the code paths taken when the file is reported as modified vs. when the file is reported as unmodified. Note also that Subversion sometimes sleeps deliberately to wait for on-disk timestamp updates. See svn_io_sleep_for_timestamps().
Re: Problem in connecting the server
On Thu, Jun 07, 2012 at 10:39:11AM +0900, Masaru Kitajima wrote: > Stefan, > > I sent an e-mail with my iptables list. Did you kindly look at it? Yes but I could not see anything wrong with it. And I don't really know a lot about iptables. One if your rules requires stateful connection tracking: ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED As far as I know this requires the ip_conntrack (or nf_conntrack) kernel module to be loaded. Is it loaded? Check with 'lsmod | grep conntrack'. > Is there anything wrong? > > The problem is not fixed yet. Please help me. At this point, I don't know what else to suggest. The problem is hard for me to diagnose remotely over email. Sorry. Also, I think we've ruled out long ago that this is a problem with Subverion itself, but probably some network configuration issue. This mailing list is primarily about problems with Subversion itself, not about iptables etc. There are other support forums for that. I would suggest that you ask a tech-savvy friend who could help and take a look at the machine together with you to locate the source of the problem.
Status after svn_client_move6
Hi all, I am new to subversion and subversion api, and I have a question which I hope someone can point me in the right direction. I am trying to do a subversion integration in the tool I am working on, and to rename a file, I believe I need to call the svn_client_move6 function. That's all good, I can see the file is being renamed in Windows Explorer after the call. What puzzles me is the svn_client_status5 call straight after. If I have an unmodified file A.txt, renaming it to B.txt and back to A.txt should give me the node status as "replaced" but text status should remain "normal". I have TortoiseSVN installed, and using the file properties dialog, I can see that the file goes into "replaced" and "normal" state. But trying to call svn_client_status5 straight after the svn_client_move6 returns the file as "replaced" and "modified" in the status5 callback. It is only on subsequent call to svn_client_status5 (after some arbitrary time) the status is correctly marked as "replaced" and "normal". Wondering is there something I am doing wrong? This is how I am calling svn_client_status5: err = svn_client_status5(NULL, mSvnClientContext, filename, &info_revision, svn_depth_files,TRUE, TRUE, TRUE, TRUE, TRUE, NULL, status5_callback, &statusBaton, mRootAprPool); Any advice or pointer is appreciated. Thuan
