Ævar Arnfjörð Bjarmason wrote:
I just tried and I can't reproduce this or the issue with the number
of objects to be uploaded drifting from what really needs to be
uploaded.
Now if I upload a per-object upload and it fails partway the objects
that were uploaded up until that point will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
Thanks a lot for your work.
I still wonder how the transition to tested works. As bug #4666 is/was really
annoying but is fixed now exists still in r3070. This has also effects on
update data (see #4663).
Please update tested to r3081.
I also
On Mon, 8 Mar 2010, colliar wrote:
I think tested should be a version without any blocker/critical bug reported
on
and being tested as unstable/latest for a week.
Theoretically it would be fine, practically this is no requirement.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Hi Colliar
Yes, you're right, that's how how most professionals in most other
commercial and OS projects work,
or at least try to work. Unfortunately, JOSM is different. The JOSM
release process is one of the
many JOSMisms which are often hard to understand for both JOSM users and
JOSM
colliar wrote:
I still wonder how the transition to tested works. As bug #4666
is/was really annoying but is fixed now exists still in r3070. This
has also effects on update data (see #4663). Please update tested
to r3081.
Dirk suggested that we maybe make comming saturday version tested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dirk Stöcker schrieb:
[flaming removed]
There has been no progress with the remaining blocker entries in the last
2 weeks. The question was whether we nevertheless make a tested or not.
There was only comment in this list and it was Yes, so
On Mon, Mar 8, 2010 at 15:04, Sebastian Klein basti...@googlemail.com wrote:
#4366 (validator: repair: overlapping ways distroys data)
Plugin issue, can be fixed after release.
#4584 (cursor not show in textfields of relations-editor)
Cannot reproduce. We don't have enough info to fix
On Mon, Mar 8, 2010 at 16:15, Apollinaris Schoell ascho...@gmail.com wrote:
On 8 Mar 2010, at 7:04 , Sebastian Klein wrote:
#4401 (JOSM does not remember what has been uploaded)
It's more like an enhancement. Too complicated, will be fixed after
release.
for me this is really a bug not
On Mon, 8 Mar 2010, Ævar Arnfjörð Bjarmason wrote:
for me this is really a bug not an enhancement. Josm is used for semi automatic
imports a lot and this creates big mess of duplicates on server/network
interrupts. I know it wasn't designed for that but Josm is just such a great
workhorse.
maybe we should add a comment that uploads should be done in 1 transaction
only until this bug is fixed.
This wouldn't really help. Even if data is uploaded in one transaction (i.e.
with exactly one upload into one changeset before the changeset is closed), we
may run into the problem if
On Mon, Mar 8, 2010 at 16:30, Dirk Stöcker openstreet...@dstoecker.de wrote:
On Mon, 8 Mar 2010, Ævar Arnfjörð Bjarmason wrote:
for me this is really a bug not an enhancement. Josm is used for semi
automatic imports a lot and this creates big mess of duplicates on
server/network interrupts. I
Yes, conflict resolution today is clearly not well-designed for mass
resolution of conflicts. Openening a dialog,
resolving the conflict, and closing the dialog again, is very tedious if
you have to resolve more than, say, 20 conflicts.
This is a major issue which I think should be adressed
On Mon, Mar 8, 2010 at 16:59, Dirk Stöcker openstreet...@dstoecker.de wrote:
On Mon, 8 Mar 2010, Ævar Arnfjörð Bjarmason wrote:
To have better conflict solving you may use Update modified from first
menu. This will produce all conflicts in one single run and allows them
to
fix in one go.
On Mon, Mar 8, 2010 at 17:01, Sebastian Klein basti...@googlemail.com wrote:
Ævar Arnfjörð Bjarmason wrote:
This is how I've been running into this:
1. Download data from the OSM server, say 20 ways
2. While I edit 10 of those 2 have been changed already, so 2/10 conflict
3. Press
On Mon, Mar 8, 2010 at 19:21, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote:
Don't fear to clutter the database for testing. If you can help us
resolving this, it's for the greater good. :)
I'll see if I can reproduce this on api06.dev.
I just tried and I can't reproduce this or the issue
Karl Guggisberg karl.guggisb...@guggis.ch writes:
Yes, conflict resolution today is clearly not well-designed for mass
resolution of conflicts. Openening a dialog,
resolving the conflict, and closing the dialog again, is very tedious if
you have to resolve more than, say, 20 conflicts.
16 matches
Mail list logo
