In message <[EMAIL PROTECTED]>
Richard Fairhurst <[EMAIL PROTECTED]> wrote:
> Dave Stubbs wrote:
>
>> this whole argument is over the format of a changeset
>> query where it would be quite possible to implement it both ways, and
>> have both available at the same time.
>
> That's a very go
Dave Stubbs wrote:
> this whole argument is over the format of a changeset
> query where it would be quite possible to implement it both ways, and
> have both available at the same time.
That's a very good point.
cheers
Richard
___
dev mailing list
de
On Fri, May 16, 2008 at 10:13 AM, Dair Grant <[EMAIL PROTECTED]> wrote:
> Frederik Ramm wrote:
>
>>> First of you might want to do rollback from Z to Y only because
>>> you want to keep Y to X.
>>
>> Changesets are a grouping of edits that make things easier because one
>> only has to work with the
Dair Grant wrote:
> If an editor wants to monitor individual edits in order to provide
> coaching
> or feedback to users, that's best done by watching user actions as
> they
> happen and providing feedback based on that (recording that info in
> the DB
> for every action for every user is po
On Fri, May 16, 2008 at 9:18 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> > Use your imagination then. If the user requests, say, a graphical
>> > representation of the changes effected by change set X, you will not
>> > want to show the intermediate steps. So you would have to collapse
Frederik Ramm wrote:
>> First of you might want to do rollback from Z to Y only because
>> you want to keep Y to X.
>
> Changesets are a grouping of edits that make things easier because one
> only has to work with the groups - e.g. not show all individual edits,
> but show the group as a whole,
On Fri, May 16, 2008 at 10:18:38AM +0200, Frederik Ramm wrote:
> A changeset can only be rolled back as a whole. The rollback of a
> changeset leads to a new, "inverted" changeset that should be tagged
> in a way to express the fact that it is a rollback of changeset X.
Huh? There is currently no
Hi,
> > Use your imagination then. If the user requests, say, a graphical
> > representation of the changes effected by change set X, you will not
> > want to show the intermediate steps. So you would have to collapse the
> > change set - something changed first and deleted later, show it only
On Thu, May 15, 2008 at 06:45:01PM +0200, Frederik Ramm wrote:
> > Out of interest, why's that a bad thing? We have several editors, for
> > example: each of them works differently and presents information
> > differently. Why do we have to have One True Rollback?
> We have enough trouble as it
On Thu, May 15, 2008 at 05:45:22PM +0200, Frederik Ramm wrote:
> > I was not aware this is also a server
> > load issue. And frankly if this is about server load then there
> > are better ways to mitigate that like rewriting the map call as
> > a C/C++ apache module...
> The map call is not involve
On Thu, May 15, 2008 at 5:13 PM, Dirk-Lüder Kreie <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dave Stubbs schrieb:
>
>> It's also possible for another changeset to edit the object in between
>> as well, so this probably shouldn't be as transparent as "catapult"
2008/5/15 Dirk-Lüder Kreie <[EMAIL PROTECTED]>:
> should it be as SVN in the way that the moment I touch an object in an
> open changeset, it is locked, so my changeset can be committed as an
> atom? Or seen from the other side, how do you rollback "meshed" changesets?
> for example User A creates
Hi,
> should it be as SVN in the way that the moment I touch an object in an
> open changeset, it is locked, so my changeset can be committed as an
> atom?
Would be nice to have but totally unusable because everything would be
constantly locked.
> Or seen from the other side, how do you rollb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frederik Ramm schrieb:
> Hi,
> If you are really interested in that kind of detail, load individual
> object histories or the minutely change files. A changeset, to me,
> should be like an SVN commit: I check stuff out, then I make umpteen
> edits u
Hi,
> Out of interest, why's that a bad thing? We have several editors, for
> example: each of them works differently and presents information
> differently. Why do we have to have One True Rollback?
We have enough trouble as it is with the small number of editors we
have. I'm all for divers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Stubbs schrieb:
> It's also possible for another changeset to edit the object in between
> as well, so this probably shouldn't be as transparent as "catapult"
> might suggest. The changeset data download will have to take this into
> account.
Ho
Frederik Ramm wrote:
> We could do rollback even now without any grouping
(We do!)
> [...]
> This collapsing would have to be implemented in every piece of software
> that deals with changesets, and my hunch is that everybody would
> implement it slightly differently.
Out of interest, why's tha
Hi,
>> The very reason for having changesets is to do some grouping and
>> filtering on the server side, instead of having to let the client do
>> everything (and incur a lot of server load and traffic along the way).
>
> I thought the reason for changesets was to have some grouping
> so we cou
On Thu, May 15, 2008 at 02:20:42PM +0200, Frederik Ramm wrote:
> If you wanted "raw" access, then you can have it - just download the
> history of every object. You can do that even now.
>
> Changesets are introduced to lessen the complexity. We want "one big
> edit", ideally associated with a c
On 15 May 2008, at 11:30, bvh wrote:
> [...]
> I think it is the client who should filter what to present to the
> user. The response of the database should be as complete as possible,
> including sending intermediate states.
>
There may be cases, such as wanting to visualise the data changes, o
Hi,
> I think it is the client who should filter what to present to the
> user. The response of the database should be as complete as possible,
> including sending intermediate states.
I disagree.
If you wanted "raw" access, then you can have it - just download the
history of every object. You
On Thu, May 15, 2008 at 01:26:56PM +0200, Frederik Ramm wrote:
> The most usable type of response for the user would certainly be:
>
> "As a result of this changeset, Object X was changed from state A to
> state B".
>
> As a user, I am not interested in the 318 intermediate editing steps;
> I
On Thu, May 15, 2008 at 12:45 PM, Christopher Schmidt
<[EMAIL PROTECTED]> wrote:
> Ah, I see now. I think that this changeset identifier is *not* the one
> you want to reupload though, so the fact that it is stored on the
> individual objects, and the 'new' changeset is stored on the tag,
> actual
Hi,
> A single changeset can change an object from version 1->15, but in
> that
> case, each of the changes within that changeset should still be
> laid out
> in the changeset response, right? so one would be the change from 1-
> >2,
> 2->3, ... 14->15? Or not?
Don't know.
The most usable t
On Thu, May 15, 2008 at 07:18:30AM -0400, Christopher Schmidt wrote:
> > But one of them will be accepted first and the other will later
> > be judged as sufficiently different, right? So the actually history
> > in the database will have two transitions, one from v1 to v2 and
> > the other from v2
On Thu, May 15, 2008 at 11:42:03AM +0200, bvh wrote:
> On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> > >> Under the current plan, yes. We didn't think it was reasonable to
> > >> push that assumption down to the clients thought.
> > > Why would that be unreasonable? In what (futu
On Thu, May 15, 2008 at 12:02:39PM +0100, Dave Stubbs wrote:
> > On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> >> It is also possible to change the same object multiple times within the
> >> same changeset, so one single changeset might catapult the object
> >> version from 1 to
On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> >> Under the current plan, yes. We didn't think it was reasonable to
> >> push that assumption down to the clients thought.
> > Why would that be unreasonable? In what (futuristic) scenario would
> > version numbers not increment mono
On Thu, May 15, 2008 at 11:46 AM, Christopher Schmidt
<[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
>> It is also possible to change the same object multiple times within the
>> same changeset, so one single changeset might catapult the object
>> versio
On Thu, May 15, 2008 at 12:50:39PM +0200, Frederik Ramm wrote:
> An online editor like Potlatch will open a changeset and then let the
> user do whatever he wants, including changing an object again and
> again and again; since edits are not buffered by the editor but
> rather uploaded whenev
Hi,
>> It is also possible to change the same object multiple times
>> within the
>> same changeset, so one single changeset might catapult the object
>> version from 1 to 15.
>
> Is that a design goal? That behavior seems unexpected to me.
An online editor like Potlatch will open a changeset a
On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote:
> It is also possible to change the same object multiple times within the
> same changeset, so one single changeset might catapult the object
> version from 1 to 15.
Is that a design goal? That behavior seems unexpected to me.
Regar
On Thu, May 15, 2008 at 06:40:41AM -0400, Christopher Schmidt wrote:
> How so? Why would you save the changeset of an individual object to a
> file?
(read entire thread, then respond, Chris: Responding in order is silly.)
--
Christopher Schmidt
MetaCarta
__
On Thu, May 15, 2008 at 09:10:42AM +0200, Martijn van Oosterhout wrote:
> On Thu, May 15, 2008 at 7:28 AM, bvh <[EMAIL PROTECTED]> wrote:
> > Well the changeset_id is certainly bogus when you save it to disk no?
> > What would you put in it? Scenario : I am somewhere in the woods with
> > JOSM/merk
On Thu, May 15, 2008 at 07:28:29AM +0200, bvh wrote:
> On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote:
> > So, we specced out what you would need for a changeset download,
> > invented old_version and new_version and then used old_version
> > everywhere we needed it. If we d
On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote:
> On Wed, May 14, 2008 at 11:04 PM, bvh <[EMAIL PROTECTED]> wrote:
> > But apparently the server code expects version, not old_version.
> > Personally I slightly prefer version as it would then become
> > identical code from ju
Hi,
>>> But isn't old_version+1 always equal to version?
>> Under the current plan, yes. We didn't think it was reasonable to
>> push that assumption down to the clients thought.
> Why would that be unreasonable? In what (futuristic) scenario would
> version numbers not increment monotonically o
On Thu, May 15, 2008 at 09:02:04AM +0100, Tom Hughes wrote:
> > But isn't old_version+1 always equal to version?
> Under the current plan, yes. We didn't think it was reasonable to
> push that assumption down to the clients thought.
Why would that be unreasonable? In what (futuristic) scenario wou
In message <[EMAIL PROTECTED]>
bvh <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 09:10:42AM +0200, Martijn van Oosterhout wrote:
>> I'm not talking abot diff upload responses, I'm talking about
>> changeset downloads. Say I note that object 123 was modified in
>> changeset 456 six w
On Thu, May 15, 2008 at 09:10:42AM +0200, Martijn van Oosterhout wrote:
> I'm not talking abot diff upload responses, I'm talking about
> changeset downloads. Say I note that object 123 was modified in
> changeset 456 six weeks ago. And I go to the API and say: show me
> everything done in changese
On Thu, May 15, 2008 at 7:28 AM, bvh <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote:
>> So, we specced out what you would need for a changeset download,
>> invented old_version and new_version and then used old_version
>> everywhere we needed it.
On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote:
> So, we specced out what you would need for a changeset download,
> invented old_version and new_version and then used old_version
> everywhere we needed it. If we do it your way then we would get
> old_version and version for
On Wed, May 14, 2008 at 11:04 PM, bvh <[EMAIL PROTECTED]> wrote:
> But apparently the server code expects version, not old_version.
> Personally I slightly prefer version as it would then become
> identical code from just saving the file.
Heh. We started from the same principles and ended up in a
On Wed, May 14, 2008 at 11:40:40PM +0200, Martijn van Oosterhout wrote:
> Now who is unilaterally making decisions? :) Sorry the wiki wasn't clear
> enough.
If you look at the irc log from tonight you 'll clearly see that
all I am looking for is documentation for the current state of affairs.
>
Now who is unilaterally making decisions? :) Sorry the wiki wasn't clear enough.
On Wed, May 14, 2008 at 7:52 PM, bvh <[EMAIL PROTECTED]> wrote:
> - When updating or deleting an object, the wiki
> says you need to include an attribute old_version with the version
> on which you base the changes (o
On Wed, May 14, 2008 at 07:52:02PM +0200, bvh wrote:
> While implementing the 0.6 api clientside, I found out two areas
> where the wiki documentation of the 0.6 api is not clear or diverges
> from the implemented reality.
>
> - When updating or deleting an object, the wiki
> says you need to incl
46 matches
Mail list logo
