Thank you for your reply.
> the mergeinfo tells that it didn't merge to that node.
Once I've resolved the tree conflict, is there a sense in which it
didn't merge everything in /trunk into /branches/branch? Marking the
tree conflict resolved doesn't remove the svn:mergeinfo property from
dir/fil
I don’t know whether it is a bug or a feature. Storing this value will make a
future merge handle the partial merge that was skipped at first: the mergeinfo
tells that it didn't merge to that node.
There are two ways to remember that: record ‘non inheritable’ info on the
direct parent, and the
Hi,
Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
it sets empty svn:mergeinfo properties for files within a
tree-conflicted directory during a merge. The effect is this:
Layout:
/trunk
/branches/branch
Add empty dir/file.txt to trunk and independently to branch.
Merge t
Op 11-mrt.-2015 18:32 schreef "pascal.sand...@freescale.com" <
pascal.sand...@freescale.com>:
>
> I'm in a company that use redhat as base distribution. I asked for a web
server to migrate some tools from an old server. I asked for recent
versions of some tools like php, perl or mysql.
> For this r
I'm in a company that use redhat as base distribution. I asked for a web server
to migrate some tools from an old server. I asked for recent versions of some
tools like php, perl or mysql.
For this reason (mostly compile a newer version of php) and to be able to put
all the binaries and configur
On Wed, Mar 11, 2015 at 11:51 AM, pascal.sand...@freescale.com
wrote:
> Hi again
>
> In fact my previous conclusion are wrong.
>
> What exactly works is svn commit from a client that is version 1.6. Using a
> svn client 1.7 or 1.8, commit does not proceed until stopped by the timeout.
>
> svn vers
Hi again
In fact my previous conclusion are wrong.
What exactly works is svn commit from a client that is version 1.6. Using a svn
client 1.7 or 1.8, commit does not proceed until stopped by the timeout.
svn version on server is 1.8.11.
What is different between version 1.6 and 1.7 or 1.8 during a
Hi
That’s something I was thinking about also but I am within a company that
‘probably’ don’t have firewall for internal traffic. I still need to confirm it.
I tried few other things directly from the server.
As I said in a previous message, I did a svn commit on the repository using URL
file:/
On Wed, Mar 11, 2015 at 2:00 AM, Stümpfig, Thomas
wrote:
> l
> Actually splitting projects is not a solution to something that eliminates
> old data.
Correct, but if we give up on getting a working obliterate, we are
left with dump/filter/load as the only way to administer content. And
as a pra
I forgot to mention, indeed, the full path in the error message indicates that
large avi files were involved in the update operation.
-Original Message-
From: Alfred von Campe [mailto:alf...@von-campe.com]
Sent: Dienstag, 10. März 2015 15:59
To: Bert Huijben
Cc: Branko Čibej; Stümpfig, Th
Hi all,
i'll try to get a Wireshark extract that covers the error. The problem I have
with it, is that Wireshark on the server will capture a huge amount of data. We
have ~20-100 parallel updates on the server. I observed peaks with 250 http
sessions. Capturing the interface for a long time will
Hi all
Actually splitting projects is not a solution to something that eliminates old
data. Think of a project with one file only. Legally one might be forced to
keep the file at least for 5 or 10 Years. But after this period the very same
old revisions of the file must be destroyed because of o
12 matches
Mail list logo
