: Subversion: checkout failed: Subversion
update_external problem for D:\work\641f829b10ee37b7\src\: svn: E175002:
timed out waiting for server
Has anyone an idea?
Regards
Florian v.Schoenebeck
* Daniel Shahaf:
> You can simply email the details to d...@subversion.apache.org, in
> addition to or instead of opening a jira ticket [jira is under
> a temporary lockdown right now].
Right, and it's still suspended. I will post to dev@.
* Stefan Sperling:
> On Sat, Apr 23, 2016 at 05:55:23PM +0200, Florian Weimer wrote:
>> It seems that mod_dontdothat creates an Expat XML parser without
>> inhibiting XML entity expansion for the internal DTD subset. This
>> might cause a denial-of-service issue when par
they are in the client code, so there is less
exposure.
May I file an issue for this?
Thanks,
Florian
* Nico Kadel-Garcia:
> On Sun, Jan 4, 2015 at 9:27 AM, Florian Weimer wrote:
>> * Nico Kadel-Garcia:
>>
>>> If possible for Subversion servers, I'd push to migrate. Finally digging
>>> through the IBM support site, I see that support for it ended in 2007
* Nico Kadel-Garcia:
> If possible for Subversion servers, I'd push to migrate. Finally digging
> through the IBM support site, I see that support for it ended in 2007.
>
> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS906-023
> One thing I recall about 1.7, is that virtually none of the changes did
> anything that really sped up checkout. So that is probably the worst thing
> to be testing with. If all you care about is checkout, then there was
> really little done in 1.7 or 1.8 to speed it up. Most of the big
> perf
> From your numbers I deduce that the performance degradation can be
> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
> * NTFS vs. ext4: roughly a factor 3 slower.
> * Windows 7 vs. Linux: roughly a factor 2.5 slower.
>
You assume that the file operation performance of Windo
ning with?
>
sqlite.x86_64 3.8.4.2-2.fc20
Thanks,
Florian
dora 20 64 bit
* Windows 7, 64 bit
* AV deactivated
* IPv6 deactivated
* Windows file indexing service deactivated
* Windows auto updates deactivated
Server Setup
$ svnserve -d --memory-cache-size 2048 -r /srv/svn_repos/
--cache-txdeltas yes --cache-fulltexts yes -c 0
Thanks for any pointers,
Florian
* Z. W.:
> Issue: For those files that User C checks in, we like to pick up the
> previous versions of those files, prior to User C's checkouts after
> the job B begins running and not pick up the files versions that
> User B checks in during the job B run.
>
> We like to know if there is anything
Hi Markus,
* Markus Schaber [2012-04-23 14:53]:
> Hi, Florian,
>
> Von: Florian Kolter [mailto:f...@floriankolter.de]
> >
> > since upgrading svn from 1.6.16 (TortoiseSVN 1.6.15) to 1.7.4 (TortoiseSVN
> > 1.7.6) my working copies are very often corrupted and clea
- Repository: https://...
Can you already guess something from this description? Can you give me
further hints?
Thanks in advance
Florian
n my later mail, pointing subversion to the Comodo
Root Certificate "AddTrustExternalCARoot" solved it.
However, I would have subversion expected to utilize the keychain of Mac OS X.
/Florian
Hi again,
> On Sep 16, 2011, at 8:28 PM, Florian wrote:
>
> Why is Mac OS X Lion not capable to checking the certificates
> correctly? To me it seems like it ignores the intermediate
> certificates served from Apache. Or is there something wrong in my
> configuration?
It did
on my mac and got the same certificate warning.
Why is Mac OS X Lion not capable to checking the certificates
correctly? To me it seems like it ignores the intermediate
certificates served from Apache. Or is there something wrong in my
configuration?
Thanks a lot for any help
/Florian
* Florian Weimer:
> Switching a working copy to a branch where a locally modified file
> does not exist, and switch back to the original branch (without
> further changes) leaves the working copy in an inconsistent state. It
> is surprisingly difficult to recover from that situatio
parent of the parent directory of the
affected file.
Is this a known issue?
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
repository paths.
(This is with 1.6.12, in case there have been subsequent
improvements.)
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
such file
> svn ls .../t...@31252
> Exists, etc
>
> You'll get the revision in at most log2 HEAD iterations
If the path has been deleted multiple times, the result won't be
stable in the sense that you're guaranteed to get the same answer if
further (unrelated) commits a
ient or
the server not to attempt X11 forwarding. You should probably do that
in any case (and it should be the default in more recent Solaris
releases).
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
s is not so obvious: I regularly get up-to-date-ness
failures during serialized development on a single repository. Those
pointless tree conflicts in "svn merge" are especially annoying.)
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstr
cally.
Is this possible with Subversion 1.6.12?
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
to take care of that. But if the
Subversion fails to do that, it cannot recover from file system
crashes, either, which is arguably a bug in Subversion.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
.6;
anyhow, if someone can verify that point with the latest release...(?)
so, is it a bug, or an issue in my (our) configuration?
thx
florian
--
----
Seydoux Florian, PhD
25 matches
Mail list logo
