I have heard this several times, that one should always update before committing to a version control system. Why is that ?
If you don't update you risk facing a conflict if someone else has edited any of the files you want to commit while you were editing them.
In source control systems like Subversion you won't be allowed to commit before you update even if changes belong to different lines - you will have to first do an update then possibly resolve conflicts, then you'll be allowed to commit. It works like this: you start committing, the Subversion repo server checks whether any of your changes conflict with recent changes, if any of them does conflict the commit is rejected as a whole.
In older systems (I can't name an example) that perhaps could cause serious problems like overwriting changes or doing an incomplete commit (some files committed, some not).
So that you are in sync with the repo and if any conflict happens it happens in your local checkout files, which you can resolve and then commit.
You need to update so that you can get the latest changes before you check in. If you don't take an update, when you come to check in then the VCS will tell you that you need to update.
you can then effectively know your changes are fully integrated with others before you check in
Related
I have always worked alone rather than in a Dev team, so this has never been an issue
I am about to take on someone else to code with so some kind of versioning control is required
I have been looking at GitHub and integrating it with Netbeans
I can make changes and commit them no problem.
I was expecting to be able to ‘check out’ a file or files which would prevent the other user(s) from editing those files while I was editing until I commit the file and check it in
Is this the normal procedure and I am missing something, or is my understanding of GitHub incorrect?
it does help with some general understanding, but is there anything to stop one of us editing a file the other one is currently editing?
No: with a decentralized version control system, there is no (optimist or pessimist) locking mechanism possible or desirable.
The reconciliation is done when you are pushing your local work to the common remote repository: if other commits have already been pushed, you will have to pull first, merge their work to your branch (or rebase your branch on top of their work), test locally and, if everything is still working, try and push again.
Minimizing conflict and avoiding multiple team members are working on the same set of file remains an organization and communication issue.
I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.
I worked with Windows Eclipse CVS and CVS did not allow me to overwrite the latest revisions – I needed to update first. At the same time one developer working on Mac constantly overwrote my files. We looked at this problem and found that his CVS Eclipse plugin allows overwriting the latest revisions without any warning.
Now I work with Mac myself using SVN Eclipse plugin and I accidentally overwrote the latest revisions from my co developer. How to prevent this overwriting? If this overwriting happens what is the graceful way of reverting to the previous revisions and committing them back to the repository?
Wait? Something is not right here...
CVS and Subversion will never let you overwrite someone else's changes. The whole purpose of version control is to allow multiple people to work on the same files at the same time.
There are two ways version control systems do this:
Checkout and Lock: The oldest systems used a checkout and lock system. That is, you checkout the code for changes, and no one else was allowed to checkout and make changes until you checked in your changes. The problem is that someone could checkout files for a week and forget to check them back in, or go on vacation. Then, everyone else is stuck unable to work.
Checkout, and first person who commits wins: In this system, two people can checkout the same file and do their work. However, the first person who finishes their changes and commits wins. The other person must do an update which will incorporate the first person's changes into their working copy before they can commit their changes. This is what Subversion and CVS do.
So, how in the world are you losing your changes? Or, how are you overwriting the other person's changes?
Sometimes this happens if you are sharing your checked out working copy with other people. This is wrong and should never be done. Instead, each user should have their own separate independent copy of the project (Heck, you can even have multiple version if you want). When your partner checks in their changes, it shouldn't affect your files.
What will happen is that when you try to commit your changes, you will be told that your working copy is out of date. You'll have to update your working copy and that will incorporate your partner's changes into your working copy. You should then verify that everything is okay, and then commit your working copy which will now include both your and your partner changes.
Does this answer your question? Are you sharing all sharing the same directory, or do you have your own working copy? Is there something else going on?
In my repository I needed to revert to an older revision. I did reverting and made the changes I needed to. How do I push the new revision upstream?
I was on rev 17 when I needed to revert back to rev 13. Now that I've made my changes, I'm on rev 18. Thing is, when I go to push these changes up (I'm using TortoiseHG), I get an error "abort:push create new remote head.
I don't want to do a merge. Do I want to do a force with the --force command or do I need to delete rev 14-17. If I need to delete, how do I delete 14-17.?
Proper solution is to actually merge with option Discard all changes from merge target (other) revision. But sometimes life is harder on us and we really need to drop some changes (eg. we committed nuclear launch codes or some other security sensitive data). Is that your case? If yes then follow.
Assuming that original changes were not published you could:
enable mq extension
r-click on offending changes and execute Modify history->Strip.
This will permanently remove changes from your local history.
You don't want to delete revisions and therefore destroy history. That goes against the reason version control exists.
You can do a merge and discard.
You can also do this in tortoiseHG.
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.