<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Matt Amos wrote:

<blockquote

 cite="mid:79d9e4e90905050414m7d0d1208u5b9eef3742560e52@mail.gmail.com"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">As

for JOSM, I have already heard complaints, and people have asked how

they can go back to the old non-changeset upload, because they

explicitly *want* as much as possible of their changeset to upload, and

are pissed off when the whole changeset fails because it contains a

change to some monster object that is changed very often.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

can JOSM split the single upload into multiple uploads within the same

changeset? perhaps having a tunable parameter to isolate "large" items

into their own separate upload?

there is no reason why one save = one upload = one changeset.

and this will help with the problem that Brett is seeing, which

might(*) be down to the following:

1. user on a slow connection hits "save", changeset created, client

begins diff upload

2. server starts transaction

3. client sends first element, which the server parses and saves

4. ... client and/or network slowness cause 5 mins to pass ...

5. client ends the diff

6. server ends the transaction

because we're assigning timestamps in rails (at step 3), but the rows

only become visible at step 6, the delay between the end of the

transaction and the timestamp on the element could be up to 24h, in

theory.

  </pre>

</blockquote>

I was under the impression that the transaction is only started once

the diff is fully uploaded.  Is that not the case?  Or is that the bit

you're unsure about?<br>

<br>

Brett<br>

<br>

</body>

</html>