|Re: Revision after check-in [message #35618 is a reply to message #35584]
||Thu, 09 October 2008 20:48
|| Thomas Hallgren
Registered: July 2009
Mark Kirchner wrote:|
> 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
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
|Re: Revision after check-in [message #542747 is a reply to message #35618]
||Fri, 25 June 2010 19:26
| olly2 Mising name
Registered: June 2010
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.01750 seconds