Re: [Subclipse-users] 1.1.4: Merge conflict during commit in freshly shared project

Miha Vitorovic <mvitorovic@nil.si> wrote on 07/31/2006 02:48:02 AM:

> You know Mark, I think he has a point in this exact scenario. After all
a
> user is sharing a project, which implies that nothing should have
happened
> to the folder between folder creation and adding files to it. After all,

> you are sharing your project, why should anyone else put files into it
> before you actually commit the content of the project.

Gunnar is not having a problem sharing the project, he is having a problem
with a change he makes after the share. Consider this scenario:

Share Project:
r1 Commit folder/checkout
r2 Commit files for project

Now delete one of those files and commit, or set properties on project
folder and commit (something that requires a folder to be at HEAD):

It will give an out of date error because the project folder is still at
r1.

We could "fix" this in the Share Project process by updating the project
folder after the r2 commit. However, now comsider this scenario:

Share Project:
r1 Commit folder/checkout
r2 Commit files for project

Trivial changes:
r3 Commit a trivial change
r4 Commit another trivial change

Now delete one of those files and commit, or set properties on project
folder and commit (something that requires a folder to be at HEAD):

Even if we implemented this "fix" it will give an out of date error
because all of the folders will be at r2.

My point being that you are going to run into this problem no matter what
we do because that is how Subversion works and we cannot issue an update
after every commit. Adding an update at the end of Share Project just
does not seem like it is really fixing anything.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Mon Jul 31 15:11:56 2006