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
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
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
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
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
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
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
* 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
* 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
* 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
* 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
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 parsing client-submitted
XML.
There are other pieces of code in Subversion which also create Expat
parsers this way, but th
* 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
* 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@.
14 matches
Mail list logo