Hi,
Ulrich Eckhardt wrote:
> > So what I did was: already having the externals checked out in the
> > Init folder in the WC linked with the destination repository I've
> > created the Source folder; then I've manually copied the stuff from
> > Init folder, I've added it, committed, and as the next
Hi, Stefan
I looked /var/log/httpd/access_log and found an error.
XXX.XXX.XXX.XXX - kitajima [30/May/2012:16:14:26 +0900] "GET /svn/
project1 HTTP/1.1" 301 249 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X
10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/
534.57.2"
This looks l
I'm using svn 1.6.11 of Centos 6.2.
I've noticed the following two issues with externals.
(1) If I have an external and then do a "svn propedit svn:externals ..." and
delete a path, the file that was previously exported into my space by "svn
update" persists in a state of limbo.
(2) An "svn me
2012/5/31 Aaron Turner :
> I keep on getting this error:
>
> svn: Checksum mismatch while updating 'interfaces.lookup'; expected:
> '2c21f93c8639901a28056a507aa54deb', actual:
> '97c86da543f396d636e960e46dec7280'
>
> on the same file over and over again. I've blown away my working copy
> of the re
On Thu, May 31, 2012 at 3:02 PM, Stefan Sperling wrote:
> [ Changing the Subject line because this thread has drifted to a different
> topic. ]
>
>>
>> But, that puts it at odds with running it on a stable Linux distribution...
>
> So what is different with any other software that these distribut
On Thu, May 31, 2012 at 2:18 PM, Jeyanthan wrote:
>
> On Friday 01 June 2012 12:33 AM, Aaron Turner wrote:
>>
>> I keep on getting this error:
>>
>> svn: Checksum mismatch while updating 'interfaces.lookup'; expected:
>> '2c21f93c8639901a28056a507aa54deb', actual:
>> '97c86da543f396d636e960e46dec7
On Friday 01 June 2012 12:33 AM, Aaron Turner wrote:
I keep on getting this error:
svn: Checksum mismatch while updating 'interfaces.lookup'; expected:
'2c21f93c8639901a28056a507aa54deb', actual:
'97c86da543f396d636e960e46dec7280'
on the same file over and over again. I've blown away my worki
On Thu, May 31, 2012 at 4:54 PM, Les Mikesell wrote:
> On Thu, May 31, 2012 at 2:53 PM, Mark Phippard wrote:
>>
>> I do not think it will ever happen though because generally Red Hat is
>> only going to backport fixes that have been deemed critical to
>> security.
>
> That's really an overgeneral
On Thu, May 31, 2012 at 2:53 PM, Mark Phippard wrote:
>
> I do not think it will ever happen though because generally Red Hat is
> only going to backport fixes that have been deemed critical to
> security.
That's really an overgeneralization - they do that within minor
release versions, but when
[ Changing the Subject line because this thread has drifted to a different
topic. ]
On Thu, May 31, 2012 at 02:44:32PM -0500, Les Mikesell wrote:
> On Thu, May 31, 2012 at 2:12 PM, Ryan Schmidt
> wrote:
> >
> >>
> >> Yes, it doesn't seem that bad today. I'm just pointing out that there
> >> wi
On Thu, May 31, 2012 at 1:45 PM, Les Mikesell wrote:
> On Thu, May 31, 2012 at 12:23 PM, Stefan Sperling wrote:
>> >
>> This policy is more a result of the community's capabilities than anything
>> else. The decision to not ship all fixes to 1.6 users is a compromise.
>> We were shipping all kind
On May 31, 2012, at 14:44, Les Mikesell wrote:
> On Thu, May 31, 2012 at 2:12 PM, Ryan Schmidt
> wrote:
>>
>>>
>>> Yes, it doesn't seem that bad today. I'm just pointing out that there
>>> will very likely be a large user base continuing to run some version
>>> of 1.6.x for 5 to 10 years in t
On Thu, May 31, 2012 at 2:12 PM, Ryan Schmidt
wrote:
>
>>
>> Yes, it doesn't seem that bad today. I'm just pointing out that there
>> will very likely be a large user base continuing to run some version
>> of 1.6.x for 5 to 10 years in the future.
>
> That's fine, if you don't mind running old so
On May 31, 2012, at 12:45, Les Mikesell wrote:
> On Thu, May 31, 2012 at 12:23 PM, Stefan Sperling wrote:
>>>
>> This policy is more a result of the community's capabilities than anything
>> else. The decision to not ship all fixes to 1.6 users is a compromise.
>> We were shipping all kinds of
I keep on getting this error:
svn: Checksum mismatch while updating 'interfaces.lookup'; expected:
'2c21f93c8639901a28056a507aa54deb', actual:
'97c86da543f396d636e960e46dec7280'
on the same file over and over again. I've blown away my working copy
of the repo and re-checked out and the problem g
On Thu, May 31, 2012 at 12:23 PM, Stefan Sperling wrote:
> >
> This policy is more a result of the community's capabilities than anything
> else. The decision to not ship all fixes to 1.6 users is a compromise.
> We were shipping all kinds of bugfixes for 1.6 users between March 2009
> and October
On Thu, May 31, 2012 at 11:41:27AM -0500, Les Mikesell wrote:
> On Thu, May 31, 2012 at 11:26 AM, Stefan Sperling wrote:
> >> >
> >> > We don't fix these kinds of bugs in the 1.6 series anymore.
> >> > The 1.6 series receives only security or data corruption fixes.
> >>
> >> Do you happen to know
On Thu, May 31, 2012 at 11:26 AM, Stefan Sperling wrote:
>> >
>> > We don't fix these kinds of bugs in the 1.6 series anymore.
>> > The 1.6 series receives only security or data corruption fixes.
>>
>> Do you happen to know how the decision is made to update the
>> subversion rpm included in RHEL6
On Thu, May 31, 2012 at 05:22:41PM +0200, Stefan Sperling wrote:
> By code inspection I would guess that 1.7 has the same problem, however.
> Can you confirm that? If so, please file an issue. I believe there might
> be a bug where the merge compares a version of the file with keywords
> expanded t
On Thu, May 31, 2012 at 11:00:58AM -0500, Les Mikesell wrote:
> On Thu, May 31, 2012 at 10:22 AM, Stefan Sperling wrote:
> >
> > We don't fix these kinds of bugs in the 1.6 series anymore.
> > The 1.6 series receives only security or data corruption fixes.
>
> Do you happen to know how the decisi
Am 31.05.2012 17:45, schrieb David Weintraub:
[SVN long distance performance problems]
> * Is there another solution? What about svnsync?
svnsync will greatly speed up the update, checkout and log access. You
can configure it to automatically push changes to connected repositories
on commit, so re
On Thu, May 31, 2012 at 10:22 AM, Stefan Sperling wrote:
>
> We don't fix these kinds of bugs in the 1.6 series anymore.
> The 1.6 series receives only security or data corruption fixes.
Do you happen to know how the decision is made to update the
subversion rpm included in RHEL6.x? Projects tha
I have a client that has a local US repository and developers all over
the world. The remote developers are complaining about slow access
times for Subversion. Some are even saying we should move to Git
(which really wouldn't help the commit times to the main repository
where builds are done).
I a
On Thu, May 31, 2012 at 02:36:56PM +0100, neil.tu...@rwe.com wrote:
> I would like to confirm this issue in v 1.6.17 - using binary files
> via TortoiseSVN. Test scenario was to create a binary file in trunk
> with the "svn:keywords = Revision" property set*; branch the trunk to
> $BAU; change the
Am 31.05.2012 16:52, schrieb Kamil Libich:
> I have not to small repository with the one piece of software. [...] I don't
> want to copy ALL history. I'd like to make a copy based on one revision,
[...]
> What I wanted to do to use svn copy command but it finishes in error saying
> the repositories
I have not to small repository with the one piece of software. This
software has a lot features; some of them are project specific, some of
them are not. I decided to 'extract' one of the non-specific features and
since that moment to maintain it in another existing repository which holds
my non-pr
Good morning!
I encountered an odd issue yesterday and I'm looking for advice on how to
resolve it. A developer performed a commit in Eclipse of over 200 files for a
project. Jenkins checked out the project but failed to build because one of
the source files was empty. I checked out a fresh
I would like to confirm this issue in v 1.6.17 - using binary files via
TortoiseSVN. Test scenario was to create a binary file in trunk with the
"svn:keywords = Revision" property set*; branch the trunk to $BAU; change the
file in $BAU (and commit); merge the change revision from $BAU back into
Guten Tag frame,
am Donnerstag, 31. Mai 2012 um 14:54 schrieben Sie:
> Suppose we have two exactly same subversion repository trees, one which
> HEAD is at revision 9000 and one which HEAD is only at revision 100. Is the
> one with low revision number performs faster? Or should be no difference?
Hi:
Suppose we have two exactly same subversion repository trees, one which
HEAD is at revision 9000 and one which HEAD is only at revision 100. Is the
one with low revision number performs faster? Or should be no difference?
the performance, I mean "svn update", "svn commit" etc.
Thank you.
On Thu, May 31, 2012 at 12:46:09PM +0900, Masaru Kitajima wrote:
> Hi, all!
>
> I do need your help.
>
> I'm running CentOS 5.8 and Subversion 1.6.11 on a VPS.
>
> When I try to connect to the repository from my client Versions.app for Mac,
> an error message is shown.
> "Could not read status l
31 matches
Mail list logo
