| Revision after check-in [message #35446] |
Thu, 09 October 2008 06:48  |
|
Hi,
I have a project with revision 100. I make a change to a file in that project and
check-in. The check-in comments end with "Committed revision 101". When I now look at the
project in the package explorer it is still at revision 100 and I have to perform an SVN
update it in order for it to reflect 101.
I would argue that the current behavior is incorrect. If I forget the update, the project
revision is wrong. It claims to be revision 100 without changes but it really isn't. The
correct behavior would be to always update the local copy after a successful commit in
order to preserve consistency.
Comments?
Regards,
Thomas Hallgren
|
|
|
| Re: Revision after check-in [message #35481 is a reply to message #35446] |
Thu, 09 October 2008 09:30  |
|
Thu, 09 Oct 2008 08:48:05 +0200, /Thomas Hallgren/:
> I have a project with revision 100. I make a change to a file in that
> project and check-in. The check-in comments end with "Committed revision
> 101". When I now look at the project in the package explorer it is still
> at revision 100 and I have to perform an SVN update it in order for it
> to reflect 101.
>
> I would argue that the current behavior is incorrect. If I forget the
> update, the project revision is wrong. It claims to be revision 100
> without changes but it really isn't. The correct behavior would be to
> always update the local copy after a successful commit in order to
> preserve consistency.
>
> Comments?
The additional update is an operation which not everybody would
want. The mixed revision working copy is well-documented case in
the SVN usage:
http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html# svn.basic.in-action.mixedrevs
--
Stanimir
|
|
|
| Re: Revision after check-in [message #35515 is a reply to message #35481] |
Thu, 09 October 2008 13:24 |
|
Hi Stanimir,
Let me elaborate what I mean a bit more. I'm mostly concerned about the use-case when a
project as a whole is checked in. This is what each member of my team has to do on every
project check in:
1. Check that the working copy contains the latest revision. Refuse the check-in
if that's not the case.
2. Do the check in.
3. Update the working copy to reflect what's latest after the check-in.
It would be great if Subversive could support this behavior out of the box. Even greater
if all three steps were executed in one atomic transaction but I'm not sure if that's
possible. I think our use-case is very very common.
In my opinion, working copies with mixed revisions should be avoided if possible. I agree
that they might be useful under rare circumstances but hardly ever when you check in the
project as a whole. To me, the Subversive client would be more useful if that esoteric
behavior was confined to individual file check-ins.
Regards,
Thomas Hallgren
Stanimir Stamenkov wrote:
> Thu, 09 Oct 2008 08:48:05 +0200, /Thomas Hallgren/:
>
>> I have a project with revision 100. I make a change to a file in that
>> project and check-in. The check-in comments end with "Committed
>> revision 101". When I now look at the project in the package explorer
>> it is still at revision 100 and I have to perform an SVN update it in
>> order for it to reflect 101.
>>
>> I would argue that the current behavior is incorrect. If I forget the
>> update, the project revision is wrong. It claims to be revision 100
>> without changes but it really isn't. The correct behavior would be to
>> always update the local copy after a successful commit in order to
>> preserve consistency.
>>
>> Comments?
>
> The additional update is an operation which not everybody would want.
> The mixed revision working copy is well-documented case in the SVN usage:
>
> http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html# svn.basic.in-action.mixedrevs
>
>
|
|
|
| Re: Revision after check-in [message #35584 is a reply to message #35515] |
Thu, 09 October 2008 17:31 |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.mark-kirchner.de
Hi,
first of all: I'm not really talking about Subversive in my following
post, more about Subversion in general.
Thomas Hallgren wrote:
> [...]
>
> 1. Check that the working copy contains the latest revision. Refuse the
> check-in if that's not the case.
Why? Subversion will automatically refuse the commit if it contains
changes to an element that is not up-to-date.
And there's another problem: It's always possible that another commit
takes place just between your update and your commit. So in the end,
you'll have to trust Subversion to detect such problems anyways.
> 2. Do the check in.
> 3. Update the working copy to reflect what's latest after the check-in.
>
> It would be great if Subversive could support this behavior out of the
> box. Even greater if all three steps were executed in one atomic
> transaction but I'm not sure if that's possible.
That's definitly not possible.
> I think our use-case is very very common.
I really don't know about that; but at least it doesn't match our
use-case here.
> In my opinion, working copies with mixed revisions should be avoided if
> possible. I agree that they might be useful under rare circumstances but
> hardly ever when you check in the project as a whole.
Subversion doesn't even know about the concept of a "project" and cannot
really distinguish between a "as a whole"-commit and a "part"- or
"single file"-commit.
Granted, Subversive/Eclipse would be able to distinguish those
commit-types, but at least I really wouldn't want it to force this
behaviour on the user.
Regards,
Mark
|
|
|
| Re: Revision after check-in [message #35618 is a reply to message #35584] |
Thu, 09 October 2008 20:48 |
|
Mark Kirchner wrote:
> Hi,
>
> first of all: I'm not really talking about Subversive in my following
> post, more about Subversion in general.
>
> Thomas Hallgren wrote:
>> [...]
>>
>> 1. Check that the working copy contains the latest revision. Refuse the
>> check-in if that's not the case.
>
> Why? Subversion will automatically refuse the commit if it contains
> changes to an element that is not up-to-date.
>
For the sake of consistency. As a general rule we never check in unless the project builds
and the application starts. If we do, we cause a lot of disturbance for everyone involved.
It doesn't matter much that changing the same element generates a conflict since many
conflicts stems from incompatibilities between changes in different files.
Person A adds a method to class Foo.
Person B adds a method with the same name to a subclass of Foo.
Both person A and person B can see that everything builds. Now A checks in. Then B checks
in. Next person who updates will not be able to build since the method in B lacks an
@Override annotation.
This is just one out of many examples.
> And there's another problem: It's always possible that another commit
> takes place just between your update and your commit. So in the end,
> you'll have to trust Subversion to detect such problems anyways.
>
If the commit in itself refuses to go through unless your working copy is up to date then
there's no problem. Sure, you would encounter situations when you just updated, then
attempted a commit that failed because someone beat you to it. So what? You just update
again an make a new attempt. The important thing is that you never succeed unless you have
the latest revision when you make your check-in attempt.
>> 2. Do the check in.
>> 3. Update the working copy to reflect what's latest after the check-in.
>>
>> It would be great if Subversive could support this behavior out of the
>> box. Even greater if all three steps were executed in one atomic
>> transaction but I'm not sure if that's possible.
>
> That's definitly not possible.
>
Why not? Doesn't the low level API allow that you start a transaction, perform a sequence
of actions, and then commit?
>> I think our use-case is very very common.
>
> I really don't know about that; but at least it doesn't match our
> use-case here.
>
>> In my opinion, working copies with mixed revisions should be avoided if
>> possible. I agree that they might be useful under rare circumstances but
>> hardly ever when you check in the project as a whole.
>
> Subversion doesn't even know about the concept of a "project" and cannot
> really distinguish between a "as a whole"-commit and a "part"- or
> "single file"-commit.
>
That's partly my point. Subversive is not Subversion. Subversive is an Eclipse IDE
extension and can provide a values to the Eclipse user that goes beyond what Subversive
can. It already does that in many ways. Subversive also provides great support for the
model using branches/tags/trunk folders even though Subversion doesn't stipulate that.
> Granted, Subversive/Eclipse would be able to distinguish those
> commit-types, but at least I really wouldn't want it to force this
> behaviour on the user.
>
Can you give me one concrete example where it is beneficial to have mixed revisions of a
project in a working copy and not knowing that you do? I would have an easier time with
this if the folder structure in some way indicated the fact with a marker. Now, it's just
invisible.
Regards,
Thomas Hallgren
|
|
|
| Re: Revision after check-in [message #542747 is a reply to message #35618] |
Fri, 25 June 2010 19:26 |
 olly2 Mising name
Messages: 27
Registered: June 2010 |
Junior Member |
|
|
Hallo,
for me the problem is something different. In SVN a checkin is not an update. This is already described in the book. That´s ok for me.
The issue in my opinion is, and this seems to be a subversive problem and NOT a generel SVn issue, that you cannot see whether you have a mixed revision WC or not in subversive. After a commit you will allways have a mixed revision WC. That is ok. The issue is, that subversive does not show the revision but the last changed revision instead.
So, imagine this: you have a single revision WC. You change some files. You commit them. Now you have a mixed revision WC. There are some use cases in SVN that should NEVER be done on a mixed WC base, like merging or branching.
Now, you cannot see what kind of WC you have. So , to get it clean again you need to make an update, even if there are NO incomming changes!!!!!!!!!!!!!!!!!!!!!!!!!!. But, in the end, THERE IS NO CHANGE IN ANY VIEW OF SUBVERSIVE. But the metadata of subversion definitly changes. You can see it using other clients, like the command line interface or svnversion.
So, you make this recomended action, the update, and you have to do it before some acitivities. But you cannot see any kind of influence on any view or any status in subversive.
Anybody who has to train people using subversion/Eclipse and Subversise: good luck.
Teacher: "Make sure you have single revision WC before starting to merge .."
Student: "How can I find out whether .."
Teacher: "You cannot. Get yourselfe a piece of paper and make a line after each update and rubber it when you commit. If there is no line on the paper you have a mixed revision WC ......."
Sorry, but I realy do not like this gap in Subversive.
|
|
|
Powered by
FUDForum. Page generated in 0.03593 seconds
] 
Search
Help
Register
Login
Home
