0.9.106: File lost after update

By the way, I was able to confirm that this is the problem.

Maybe when you do a commit we should/could force a complete
refresh of the
Synchronize view?

Mark


____________________________________________________________
_________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe
Plc by IBM Email Security Management Services powered by
MessageLabs. 
____________________________________________________________
_________________

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org

Mark Phippard wrote:
> By the way, I was able to confirm that this is the
problem.
>
> Maybe when you do a commit we should/could force a
complete refresh of the
> Synchronize view?
>   
Basically that was what I was suggesting by
"invalidating" synchronize.
Whether or not you update to Head, I think this will still
be needed.
Updating to head would have been the behavior that I was
expecting.


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org

DM Smith wrote:

>> By the way, I was able to confirm that this is the
problem.
>>
>> Maybe when you do a commit we should/could force a
complete refresh of
>> the
>> Synchronize view?
>>   
> Basically that was what I was suggesting by
"invalidating" synchronize.
> Whether or not you update to Head, I think this will
still be needed.
> Updating to head would have been the behavior that I
was expecting.

As I see it, the problem is a mix of revision numbers (ie.
what you want
 to achieve is "update to the latest revision of my
branch" and not
"update to revision 100").

So we have these scenarios (in Synchronize):

- Incoming change. Here, you know the base revision (wc) and
the new
revision. During update, find the highest revision on the
server for the
current branch (it's not be enough to just find the highest
rev of all
incoming changes; see below) and update all files/dirs to
it.

Caveat: Updating a dir might delete it (and the files in
it).

- Outgoing change: When a user does a commit of some files
during a sync
run (ie. you have now incoming changes, new revisions due to
the commit
and changed working copies which will are not revisions,
yet), then
update the highest known revision number after the commit.

So my guess is that you must somehow figure out what the
highest revsion
in your current branch is.

From this point of view, I wonder how subversion solves
this. What
happens when I checkout a branch and then run svn up in it?
What
happens, when I update a branch to the highest revision
number on the
server? That can't be the same as updating to HEAD, can it?

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our
imagination.
Follow me and I'll show you something beyond the
limits."
http://www.philmann-dark
.de/

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org

Aaron Digulla wrote:

> - Outgoing change: When a user does a commit of some
files during a sync
> run (ie. you have now incoming changes, new revisions
due to the commit
> and changed working copies which will are not
revisions, yet), then
> update the highest known revision number after the
commit.

Open issue here: Imagine two users A and B. File X in the
repo is newer
than their working copies.

A runs synchronize
B runs synchronize
A commits file X
B updates file X

What will B expect to get?

Worse:

A runs synchronize
B runs synchronize
A commits file X
B updates file X
B changes file X
B commits file X
A updates dir of file X

(note: both users run sync just *once*).

Will A expect the file to change?

Maybe the only solution is to go back to individual updates
but to group
them by revision numbers:

- Remember the highest revision number during population the
sync view.
- For all files which are committed individually, remember
the highest
rev for them. Don't touch the revs for the other (incoming)
files.
- For all incoming changes, update to the number we got
during the
population step. This includes directories but not the files
in them
(non-recursive update).

Another solution: During sync, request an actual update but
don't apply
it, yet. Apply the parts of the update individually when the
user
requests it.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our
imagination.
Follow me and I'll show you something beyond the
limits."
http://www.philmann-dark
.de/

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org