Re: incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

In 1.6, we erroneously used the containing directory's revision for the file in certain cases. 1.7 is correct: the file is not changed until r4. Maybe the directory has, but that is independent of the file. Cheers, -g On Jun 19, 2012 3:02 AM, "Vincent Lefevre" wrote: > I've upgraded Subversion f

incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5

I've upgraded Subversion from 1.6.17 to 1.7.5 (Debian/unstable). And there's the following problem: Subversion 1.7.5 no longer notices a change of revision of some file when a parent directory has been moved. In particular, this yields incorrect keyword expansion. The bug can be reproduced with t

Re: Connections get not closed

On Mon, Jun 18, 2012 at 10:40:49AM +0200, Joern Mueller wrote: > Hello all, > > I already sent this issue to the users list some days ago, but so far did not > get any hints from there. As this unclosed connections are really causing > problems for our server, I´m consulting the devlist now also

Re: crash in svn_client_url_from_path2

On 18.06.2012 21:37, Daniel Shahaf wrote: I think it's a bug to pass url=NULL to svn_client_url_from_path2(). Are you saying there is another bug here? I never pass NULL. Even if the call to svn_dirent_canonicalize() would return NULL I still pass an empty string in that situation. Stack tr

Re: crash in svn_client_url_from_path2

I think it's a bug to pass url=NULL to svn_client_url_from_path2(). Are you saying there is another bug here? Stefan Küng wrote on Mon, Jun 18, 2012 at 21:04:53 +0200: > Hi, > > There's an access violation happening in svn_client_url_from_path2(). > Stacktrace attached. > > Seems there's a situat

[PATCH]: Add 'replaced' value to ConflictDescriptor.Reason

Hi, enum svn_wc_conflict_reason_t has 10 possible values but ConflictDescriptor.Reason from javahl only 6; as I understand this is because some of svn_wc_conflict_reason_t values are "experimental" (for 1.8); but anyway at least 1 of those values is released (svn_wc_conflict_reason_replaced tha

crash in svn_client_url_from_path2

Hi, There's an access violation happening in svn_client_url_from_path2(). Stacktrace attached. Seems there's a situation where work_del_relpath can be NULL. Can't figure out however what that situation exactly is. Crash dump available here: https://www.crash-server.com/Problem.aspx?ClientID=t

Re: svn delete fails with "403 Forbidden" if root is not readable

Hello again, I've fixed the issue in SVNKit: http://svn.svnkit.com/repos/svnkit/trunk/ at r9286 The approach is to use common ancestor instead of repository root to run editor calls. For example, to remove paths: directory/subdirectory1/file1 directory/subdirectory1/file2 directory/subdirector

Re: Open mailing lists

Yes again sorry this is probably the wrong place to opine on this topic. I generally use disposable email addresses but accidentally used a permanent long term address at one point, otherwise I'd just have cut off the bleeding there. I don't think it's easy for everyone to generate lots of dispos

Re: AW: Shell script to make a log message template

Thank you very much! :) Carlos Andrade http://carlosandrade.co 2012/6/18 Julian Foad > The mail archive at > presents it a bit better: the attachment is not base-64 encoded, and the > message body is formatted better, but still not properly.

Re: Open mailing lists

s...@feb17.org wrote on Mon, Jun 18, 2012 at 07:16:01 -0700: > On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote: > > It should also be pointed out that a spammer could easily subscribe > > directly to the list and get all the address information that way, > > completely by passing any

Re: Open mailing lists

On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote: > It should also be pointed out that a spammer could easily subscribe > directly to the list and get all the address information that way, > completely by passing any archives. > > For completeness, the ASF's public archive policy, wh

Re: Open mailing lists

It should also be pointed out that a spammer could easily subscribe directly to the list and get all the address information that way, completely by passing any archives. For completeness, the ASF's public archive policy, which we adhere to, is here: http://www.apache.org/foundation/public-archive

Re: Confusing error message when updating colliding externals

Yes, I think it's a good idea to at least note this in the issue tracker (makes it at least discoverable by other users running into it). And if you know how to fix it ... that would be even better of course :-). But even only having the issue is useful. -- Johan On Mon, Jun 18, 2012 at 10:21 AM

Re: AW: Shell script to make a log message template

The mail archive at presents it a bit better: the attachment is not base-64 encoded, and the message body is formatted better, but still not properly. I am attaching the script again now, as plain text.  Apologies for attaching it as 'applica

Connections get not closed

Hello all, I already sent this issue to the users list some days ago, but so far did not get any hints from there. As this unclosed connections are really causing problems for our server, I´m consulting the devlist now also with it. (Sorry for crossposting.) I'm using the svn 1.7.5 SDK on Win3

Confusing error message when updating colliding externals

Hi, >From the #svn channel just a few minutes ago. The error message clearly is not that helpful for normal users. Should I file an issue for that? 09:45 < stummi> hi there. I set an external. (svn propedit svn:externals . on the root of the working copy, with the Entry "Extern svn://svnserv

Re: Open mailing lists

Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-p