RE: Empty username in repo
Thanks for the hint! Turns out there was a around the access control's Requires', and NetBeans didn't find it needed to forcefully send authentication info. Barnabás Králik -Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: Friday, March 05, 2010 2:45 PM To: Králik Barnabás Cc: users@subversion.apache.org Subject: Re: Empty username in repo You said you were using HTTP. Have you looked at the Apache Access Log? On Redhat, those are in /var/logs/httpd/access_log. I'm not sure where they are on Windows. On a Mac, you can find it under the Console.app application. Subversion itself doesn't have a user database. It gets the user name from either the environment the user is on, or in the case of HTTP, from the Apache server. The Apache Access Log will at least let us see whether or not the user was able to do the commit without signing on. Is possible that someone used the file:// protocol on the Subversion repository server itself? Most shops have their Subversion repository server unaccessible to their users. However, I've seen a few shops which use a desktop machine for their server, and users are able to access that machine directly. On Fri, Mar 5, 2010 at 3:06 AM, Králik Barnabás wrote: > I do require the user to sign in. I'm not running svnsync. > Also, svn pl -r 19 (19 is a revision in which "?"-authored files appear) says nothing. > > Barnabás Králik > > -Original Message- > From: David Weintraub [mailto:qazw...@gmail.com] > Sent: Friday, March 05, 2010 7:34 AM > To: Králik Barnabás > Subject: Re: Empty username in repo > > Several things: > > Do you reqire the user to sign on? If not, it is possible for the > user name to be blank. > > Another possibility, is it possible that someone or some process did a > "svn propset --revprop -r $rev svn:author" on the repository? That'll > change the author's name (and can make it blank). You're not running > svnsync. Are you? > > -- > David Weintraub > da...@weintraub.name > Sent from my iPhone while riding in my Ferrari. (Jealous?) > > On Mar 4, 2010, at 6:54 PM, Králik Barnabás wrote: > >> Hello! >> >> >> >> As an SVN server I have subversion 1.6.9 w/mod_svn 1.6.9 on a Debian >> box. Authentication is HTTP Basic through HTTPS against an LDAP >> directory. Sometimes when doing a commit the username field is empty >> in the repository (svn ls shows a "?"). I am using two clients: >> TortoiseSVN (1.6.7.18415 64 bit built against svn 1.6.9) and the >> NetBeans bundled client (version 1.8.1.42.1) Where can I begin to >> look for an answer? Has anyone gotten into such a problem? >> >> >> >> Thanks for your help, >> >> Regards, >> >> Barnabás Králik >> >> > > -- David Weintraub qazw...@gmail.com
Re: SVN Bug? mergeinfo being stamped on wrong files
On Fri, Mar 05, 2010 at 01:40:24PM -0500, Brad Heide wrote: > For example, when I look at the history of revision 31673 in branch > /modules/Core3/branches/3.12.x this is the only change in the log: > > /modules/Core3/branches/3.12.x/Res/Std/En_US/str/Global.string > > So revision 31673 had nothing to do with CliShell.cpp. How this revision > got stamped on the mergeinfo of CliShell.cpp in the 3.15.x branch I have > no idea. It's perfectly valid to record mergeinfo on a path for a revision which did not affect the path itself. Subversion cannot know if a revision affected a particular path without looking at the revision, which might mean contacting the repository for information. Recording the revision as merged even though it did not affect the path saves Subversion from having to ask itself "did the revision affect this particular path and do I still need to merge it into this path?" again in the future, i.e. avoid contacting the repository again to get this information. Consider how this logic applies to entire revision ranges being marked as merged. E.g. mergeinfo like "/trunk:30-244" on your branch root does *not* imply that any of the revisions 30 through 244 affected trunk. It's possible that trunk was last modified in revision 29, you created the branch in revision 30, then did a sync merge to trunk in revision 245 (which was a no-op except for mergeinfo changes) and then trunk is modified again, for the first time since revision 29, in revision 246. In this example, commits in the range 30-244 were either affecting your own branch or other branches. But Subversion can record the entire range as "merged", meaning "I've looked at all of this and any changes made to /trunk from r30 to r244 (there were none) are included in this branch -- I don't need to ask myself this question ever again". > Figuring that the merginfo was all messed up on the affected files and > folders, I removed the mergeinfo property from just the affected files and > folders and committed the change. I then re-ran my test of re-merging > something that was already merged and this time no differences showed up > in the working folder (good!) So my problem appears to be fixed for now. > How the bad mergeinfo got on these particular files I still don't know but > I will keep an eye out to see if it happens again. OK. Glad to hear you could fix the problem! Stefan
Re: Could not un- and re- link ~/.subversion/config
On Mar 5, 2010, at 09:21, Alan Brogan wrote: > There is no subversion server on those machines, they are used as subversion > clients only, so >No - subversion was not running at the time A Subversion server process would never do anything with ~/.subversion; only a Subversion client would. > If subversion has no such special logic how come it happens >on three different machines, on 9 different OSes ? >And on all of them happens *only* in the directory ~/.subversion ? As someone explained earlier in the thread, a Subversion client recreates the ~/.subversion directory when it runs, so something is causing a Subversion client to run. The only explanation I can think of is that on all three machines, something you've done is causing a Subversion client to run. A Subversion client does not have any kind of persistent process that stays running, so nothing in Subversion is designed to have the behavior you observe.
Re: Happy 6th birthday, Subversion.
Ben Collins-Sussman writes: >And happy birthday to Karl Fogel and Sander Striker as well. :-) I'd say Subversion is wearing its years better, but thanks :-). -K >On Tue, Feb 23, 2010 at 7:34 AM, Giulio Troccoli > wrote: >>> On this day six years ago, and after spending about four >>> years in the collective community womb, Subversion 1.0 was >>> released. Happy birthday, Subversion! >> >> Happy birthday. And thank you to all the developers for making it what it is >> now (and for keep improving it). Although we (the users) won't say it very >> often, your work is very muhc appreciated. >> >> Giulio >> >> >> >> Linedata Services (UK) Ltd >> Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB >> Registered in England and Wales No 3027851 VAT Reg No 778499447 >> >> >> >> >>
