Revisions in SVN are repository wide, that's how it works. If
VersionCheck.java only changed in revisions 30000 and 30054, then the URLs
all point to the same entry in the repository, and only
points to something different.
When you update to 30052, SVN puts the base version of you working
directory in the state that it was just after revision 30052 was
committed. Normally, local changes are preserved, but since you
committed your local changes, it's not a local change anymore. :)
It's probably explained better in the SVN book.
On 12/1/2010 2:23 PM, jcompagner wrote:
> no svn shouldnt update to head
> SVN should update to the revision i tell him to (in my example 30052)
> But it should overwrite files that i committed myself somewhere in the
> same project that is committed as 30054
> So what really happens is that my committed file of revision 30054 is
> replaced with a completely other revision (not even 30052 because that
> file isnt in that commit, but it was replaced with revision 30000 of
> that file)
> And what i really want in the synchronize view update
> "update C:/workspace_trunk/j2db_server -r 30052 --force"
> i really want to get only the files that are really in THAT revision
> and nothing more..
> If that did contain my file that i committed then i couldnt commit it
> anyway because then i had a update conflict and i had to update first
> before i could commit.
> On Wed, Dec 1, 2010 at 14:09, Andreas Haferburg
> <haferbur_at_inf.fu-berlin.de> wrote:
>> On 12/1/2010 11:30 AM, jcompagner wrote:
>>> Then i did a synchronize (or maybe that was done earlier) and i
>>> started updating incoming changes
>>> now subclipse sends the command:
>> I don't know if I understand correctly, but I think you're saying that you
>> did an update from within the Synchronize view, and got a different revision
>> than what you expected.
>> Please note that the Synchronize view does not have an "Update to HEAD"
>> action, but just "Update". When you synchronize with the repository, it
>> synchronizes with whatever revision HEAD points to at that time, which
>> apparently was 30052 in your case. You then committed, which made HEAD point
>> to 30054. But if you update from within the Synchronize view, it updates to
>> whatever you synchronized with, which is 30052.
>> Just yesterday I stumbled upon that and realized that that's a very useful
>> feature of Subclipse. Let's say you synchronize, go through all the changes
>> one by one, then finally decide that you can safely update. In the meantime,
>> someone else commits something that would conflict with your local changes.
>> Would you really want Subclipse to update to HEAD in this case? I sure
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-12-01 14:52:08 CET