> From: Geoff Field
> Sent: Friday, 16 August 2013 11:56 AM
> Thanks to everybody for their patience with my issue. The
> root cause is not really solved, but at least I (and my
> colleagues) can get back to normal work patterns.
>
> I've finally managed to get the upgrade to Apache 2.2 and SVN
Thanks to everybody for their patience with my issue. The root cause is not
really solved, but at least I (and my colleagues) can get back to normal work
patterns.
I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9
running. As it turns out, my former colleagues had del
> From: Philip Martin
> Sent: Thursday, 15 August 2013 19:02 PM
> Geoff Field writes:
> > I've just commented out the "AuthzSVNAccessFile" line and have done
> > the following:
This time, I changed the "AuthType" line to "AuthType None" for the Subversion
location. Similar test (but with fewer
On Thu, Aug 15, 2013 at 6:09 PM, wrote:
>
> If a project doesn't want to accept a change, they "fork" to a new
> "history". The tool does this with a svn cp
> and an update to the svn:externals property. They now
> lose sight of what the other project commits after that fork though. The
> ba
> >> The commit won't complete you'll get an out of date error.
> >
> > That's right, isn't it. It'd be no different than two folks trying to
> > commit the same file around the same time, right (one would get an out
of
> > date error)?
>
> Right, but when working on the trunk explicitly you'd e
On Thu, Aug 15, 2013 at 5:14 PM, wrote:
>
>> > I'd actually expect it to be pretty confusing if you had multiple
>> > people committing changes based from different back-rev pegged
>> > references anywhere near the same time frame. Does your external
>> > 'notify about new versions' tool help wi
Ben Reser wrote on 08/15/2013 02:57:23 PM:
> On 8/15/13 1:05 PM, Les Mikesell wrote:
> > I'd actually expect it to be pretty confusing if you had multiple
> > people committing changes based from different back-rev pegged
> > references anywhere near the same time frame. Does your external
> >
On 8/15/13 1:05 PM, Les Mikesell wrote:
> I'd actually expect it to be pretty confusing if you had multiple
> people committing changes based from different back-rev pegged
> references anywhere near the same time frame. Does your external
> 'notify about new versions' tool help with that? Don't
On Thu, Aug 15, 2013 at 4:03 PM, wrote:
>
>>
>> I'd actually expect it to be pretty confusing if you had multiple
>> people committing changes based from different back-rev pegged
>> references anywhere near the same time frame. Does your external
>> 'notify about new versions' tool help with th
> >
> > It commits a new revision of what the file external pointed to -
pretty
> > handy. If you are pegged, it will not automagically update your
pegged
> > revision (as I'd expect), so unless you are on the HEAD or update your
peg
> > to what just committed, an update will revert your WC bac
On 15.08.2013 21:08, Daniel Richard G. wrote:
> I am building Subversion 1.8.1 on Solaris 10 on AMD64, using the vendor
> compiler. All of the compile lines produce a warning from the compiler:
>
> /bin/bash /tmp/subversion-build/libtool --tag=CC --silent --mode=compile cc
> -std=c90 -D__EXTENSIO
On Thu, Aug 15, 2013 at 2:03 PM, wrote:
>
>> > We do want to modify in place. Copying back creates an additionalstep
>> > that
>
>> > is already managed quite well by SVN with externals.
>>
>> I've never done that with a file external - where does the commit go?
>
>
> It commits a new revision o
On Thu, Aug 15, 2013 at 9:03 PM, wrote:
...
> The whole discussion has centered on an attempted work around for the
> connection caching that doesn't currently occur for externals. If that can
> happen, I think we'd be very content. We're accepting of some performance
> issues. There was an XK
On Thu, Aug 15, 2013 at 2:24 PM, wrote:
>
>> >> With more complexity comes more bugs and process missteps. We're
>> >> really
>> > striving to keep things as simple as possible. We're fundamentally
>> > accepting of update times going from 2 seconds to 2 minutes. Its harder
>> > when 2 minutes
> On Thu, Aug 15, 2013 at 2:03 PM, wrote:
> >
> >> With more complexity comes more bugs and process missteps. We're
really
> > striving to keep things as simple as possible. We're fundamentally
> > accepting of update times going from 2 seconds to 2 minutes. Its
harder
> > when 2 minutes bec
On Thu, Aug 15, 2013 at 2:03 PM, wrote:
>
>> With more complexity comes more bugs and process missteps. We're really
> striving to keep things as simple as possible. We're fundamentally
> accepting of update times going from 2 seconds to 2 minutes. Its harder
> when 2 minutes becomes 20 minute
I am building Subversion 1.8.1 on Solaris 10 on AMD64, using the vendor
compiler. All of the compile lines produce a warning from the compiler:
/bin/bash /tmp/subversion-build/libtool --tag=CC --silent --mode=compile cc
-std=c90 -D__EXTENSIONS__ -D_REENTRANT-DSOLARIS2=10
-D_POSIX_PTHREAD_SE
> On Thu, Aug 15, 2013 at 12:39 PM, wrote:
> >
> >> But regardless of how you identify the target
> >> file, there shouldn't be any effective difference between copying a
> >> version into your directory or using a file external as long as you
> >> don't modify it in place and commit it back - s
On Thu, Aug 15, 2013 at 10:30 AM, Lieven Govaerts
wrote:
> On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn wrote:
>> On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
>> wrote:
...
>>> How do I enabled debugging in .subversion/config or .subversion/servers? It
>>> used to be something like "neo
On Thu, Aug 15, 2013 at 12:39 PM, wrote:
>
>> But regardless of how you identify the target
>> file, there shouldn't be any effective difference between copying a
>> version into your directory or using a file external as long as you
>> don't modify it in place and commit it back - something you
Hi All
We have a situation where a few folks dont use --reintegrate option when
performing svn merge, while others do.
What's
1- the consequence of not using --reintegrate option; can the feature
branch continue to svn merge to trunk the 2nd time and thereafter ?
2- the impact on those feature b
> > The challenge I then see on this is one of finding all instances of
foo.c.
> > If you have foo.c copied/forked fifty times to different projects,
each of
> > which has branched a couple of times, how do you programmatically find
all
> > different instances of foo.c (to let a developer choose
On Thu, Aug 15, 2013 at 12:23:35PM -0400, Thomas Harold wrote:
> We get around this whole issue with our users by either always
> saying "Subversion" instead of "subversion" so that it's clear we're
> talking about a proper noun instead of a verb. Or by just using
> "SVN".
Ah, the Secret Vigilant
On 2013/08/12 5:25 PM, Mauricio Tavares wrote:
> On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer wrote:
>> On 08/12/2013 03:51 PM, Greg Stein wrote:
>>> Apache Subversion actually started as "Inversion" around December
>>> 1999, or January 2000. It wasn't until April 2000, that we accepted
>>> "Subv
On 8/12/2013 8:03 PM, Nico Kadel-Garcia wrote:
No one else remember the old "Satan" monitoring toolkit, that had an
option to change the displayed name and icon to "Santa"?
The name "Subversion" has enough positive reputation that changing
it, just to avoid NSA style monitoring, seems very desta
Hi, all!
I wanted to check if anyone else experienced similar issue like the on I
have. I have svn server running on Windows XP as service (using
svnserve.exe). Everything was working fine until I switched server from 1.7
to 1.8. From that moment, every few days, SVN server would freeze eating up
On Thu, Aug 15, 2013 at 10:12 AM, wrote:
>
>> > Once you copy, you break the link. If you were to make a change to the
>> > copy, no one else would then see it.
>>
>> No one else would see it with externals either, except that you
>> wrote a custom tool to analyze the externals, see if a newer
>
> > Once you copy, you break the link. If you were to make a change to
the
> > copy, no one else would then see it.
>
> No one else would see it with externals either, except that you
> wrote a custom tool to analyze the externals, see if a newer
> revision of the original exists, and show t
On 08/15/2013 06:18 AM, Johan Corveleyn wrote:
On Mon, Aug 12, 2013 at 10:57 PM, Glenn Holmer wrote:
On 08/12/2013 03:51 PM, Greg Stein wrote:
Apache Subversion actually started as "Inversion" around December
1999, or January 2000. It wasn't until April 2000, that we accepted
"Subversion" as
Johan Corveleyn writes:
> Now, playing "user's advocate": is there still something useful to do
> here? I.e. apparently ra_neon worked fine with the broken servers.
> Should ra_serf also be able to handle this, so 1.8 clients can still
> work fine with servers < 1.6.17?
It appears to be related
On Thu, Aug 15, 2013 at 6:19 PM, Bert Huijben wrote:
> Hi Felipe,
>
> Do you have access to the repository configuration at the server?
>
> Things we are most interested in is how exactly your authentication is
> setup. E.g. do you allow anonymous acces, and if yes in what
On Mon, Aug 12, 2013 at 10:57 PM, Glenn Holmer wrote:
> On 08/12/2013 03:51 PM, Greg Stein wrote:
>>
>> Apache Subversion actually started as "Inversion" around December
>> 1999, or January 2000. It wasn't until April 2000, that we accepted
>> "Subversion" as a rename. It had "version" in the name
On Thu, Aug 15, 2013 at 12:12 PM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Philip Martin [mailto:philip.mar...@wandisco.com]
>> Sent: donderdag 15 augustus 2013 11:41
>> To: Felipe Alvarez
>> Cc: Hiroharu Tamaru; Users Subversion Apache; Johan Corveleyn; William
>> Smith
>> S
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 15 augustus 2013 11:41
> To: Felipe Alvarez
> Cc: Hiroharu Tamaru; Users Subversion Apache; Johan Corveleyn; William
> Smith
> Subject: Re: svn 1.8 causing locks to be broken on update
>
> Fe
Felipe Alvarez writes:
>> I'm using a 1.8.x client and a 1.6.x server and I can't reproduce it. I
>> tried this
>>
>> svnadmin create repo --compatible-version 1.6
>> svn co http://localhost:/obj/repo wc
>> svn mkdir --parents wc/A/B/C
>> touch wc/A/B/C/f
>> svn add wc/A/B/C/f
>> svn ci -mm w
Geoff Field writes:
> I've just commented out the "AuthzSVNAccessFile" line and have done
> the following:
> C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
> Adding test6.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test6.txt' is out
On 13.08.2013 02:03, Nico Kadel-Garcia wrote:
> No one else remember the old "Satan" monitoring toolkit, that had an option
> to change the displayed name and icon to "Santa"?
>
> The name "Subversion" has enough positive reputation that changing it, just
> to avoid NSA style monitoring, seems ve
On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn wrote:
> On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
> wrote:
>>>
>>> I have the same issue.
>>>
>>> It happens when I run 1.8.1 windows client with 1.6.9 https
>>> repository sever. I haven't tried so many combinations ATM,
>>> but here are
Hi Felipe,
Do you have access to the repository configuration at the server?
Things we are most interested in is how exactly your authentication is setup.
E.g. do you allow anonymous acces, and if yes in what way?
Posting your server configuration (with passwords and priva
Sorry,
I forgot to mention the versions.
Server is version 1.7.8( r1419691) on Apache httpd 2.2.23 64Bit running on a
Windows 2008 Server.
My client is version 1.8.1 (r1503906).
Best regards,
Mark
Pepperl+Fuchs GmbH, Mannheim
Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vo
40 matches
Mail list logo
