I have been using TortoiseSVN for a while now and just recently started using the eclipse plugin subclipse. I am really happy with it, although there is some stuff confusing me.
I have a few projects, which each have a different subfolder in the repository. I never worked with branches (so far), so my SVN use was fairly easy.
Update to head
Solve conflict if there are any
Make some changes in the code/project
Commit (Tortoise tells me, if an update is neccessary before)
Now with subclipse, I fell that there are other possibilities. For instance, what's with the synchronize view? I don't really get it. At the moment, I use Team->Update to head/Commit on the project folder and if there are conflicts, I use Team->Edit conflicts... on the conflicted file. That's it. So I never touch the synchronize stuff. I haven't really found a good explanation on the subclise page or google...
Is the idea to just synchronize and everything is done automatically or what?
Basically, I am asking for the workflow (or some link to a good basic explanation). I am not asking, what is possible or what does what, but how subclipse is intended to be used for small projects (<100 files, <5 persons working on it, no branches so far).
I do not think there is any reason to use the Synchronize view if you do not want to. I really like just doing Team > Update and then resolve whatever conflicts occur. That is much more the "SVN-way" to do it. The Synchronize view comes from Eclipse world, so Subclipse had to support it.
TortoiseSVN does have an option that is kind of/sort of like the Synchronize view. It is the "Check for Modifications" option. Particularly when you press the "Check Repository" button.
Also, keep in mind that the Synchronize view does not show "conflicts" the same way as SVN. In SVN, a conflict means that it could not auto-merge the change in to your file. In the Synchronize view, it means you have local modifications to a file that has incoming changes. It is possible, perhaps even likely, that SVN could automatically merge those changes if you just did an update. Personally, I would rather just let SVN try to do it.
The synchronization view allows you to recognize conflicts before you perform an update. If you perform an update and you are getting conflicts this means that you have to stop what you were doing before and start solving the conflicts. This is an interruption of your work-flow.
Usually if you perform an update and get conflict(s) you loose the ability to run and debug your program. using the synchronization view you can update the conflicting files one-by one, which allows you to integrate the remote changes step-by-step into your project.
Therefore you can start solving the conflict without loosing the ability to run your program. Or you see that there are many conflicts and decide that it is not a good time to perform an update at this time.
Hence the synchronization feature is very powerful if it comes to detecting, preventing or solving conflicting changes in an SVN.
Related
I made some changes to my project tonight and messed some stuff up. Is there a way I can go back to how the project was when I opened it? I added/deleted some files but I don't see a way to go back. My last time machine backup was from a few days ago also.
It won't help with the immediate problem, but you need to start using source code control.
This is exactly the sort of problem that source control solves. In Xcode 4 Apple make it particularly easy to start using source code control, as whenever you create a project it offers to create a Git repository for you.
Even for the smallest personal projects, source control is well worth the effort.
There is a possibility to roll back changes if you use XCode's snapshots feature. XCode 4 suggests making a project snapshot before refactoring, for example.
If you don't have the habit to commit or stash changes often (or happen not to use source control at all), snapshots are a nice tool to use before making any major changes that may break the project.
In your current situation though, you're out of luck. Sorry.
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.
when i startup eclipse, first thing i usually do is updating my source code to pull in changes from other developers (or from my home work). Sometimes i just forget it. But as we are usually working in a small team on HEAD, we all usually want to have the latest sources.
It would be nice to let eclipse automatically (like every hour or so), synchronize its workspace with CVS server and mark the project with a label for pending updates (of course it shoul dnot update the source code automatically!)
I have searched the web for it and i found some comments on CVS watch/edit feature. But i don't like to call edit every time i work on a file and i don't want to be informed by mail. All i need is a little icon at my project which says "You might run cvs update before you work on".
Is something like this available as a feature in eclipse?
regards
Janning
Well, what you're asking for is precisely what the CVS watch/edit feature is for. I agree that the emailing issue is a major PiTA but hey - remember - CVS is quite old; many CVS concepts appear a bit odd nowadays, whereas they appeared more reasonable when CVS was first written.
I cannot think of any internal, Eclipse-provided way to do what you're asking. You basically need the "Synchronize" view to be updated periodically - and, the way that the CVS plugins are written - that view is only populated upon startup and whenever you select "synchronize with repository".
Isaac
I am starting to get a reputation at work as the "guy who breaks the builds".
The problem is not that I am writing dodgy code, but when it comes to checking my fixes back into source control, it all goes wrong.
I am regularly doing stupid things like :
forgetting to add new files
accidentally checking in code for a half fixed bug along with another bug fix
forgetting to save the files in VS before checking them in
I need to develop some habits / tools to stop this.
What do you regularly do to ensure the code you check in is correct and is what needs to go in?
Edit
I forgot to mention that things can get pretty chaotic in this place. I quite often have two or three things that Im working on in the same code base at any one time. When I check in I will only really want to check in one of those things.
A few suggestions:
try work on one issue at a time. It's easy to make unrelated changes to the codebase that then end up being committed as one big chunk with a poor log message. Git is excels here since you can so easily move switch branches, and stash and cherry pick changes.
run the status command before a commit to see which files you've touched and if you've created new files that need to be added to version control.
run the diff command to see what you've actually changed. Often times you find that you've left in some debug logging that should be taken out or made some unnecessary change that is just cluttering up the diff. Try to make your diffs as small and clean as possible.
make sure your working copy builds with your changes in it
update before checking in and make sure that your working copy builds with other peoples changes in it
run what ever smoke test suite you might have to make sure that your changes work correctly
make small and frequent commits. It's a lot easier to figure out what has broken the build when the breaking commit is small.
Other things that the team can do is setup a continuous integration server like David M suggested so that the broken build is discovered as soon as possibly and automatically.
I usually always do a Get Latest before, then build. If build is good then I check in my code.
Here is what I have been doing. I have used ClearCase and CVS in the past for source control, and most recently I have been using Subversion and Visual Studio 2008 as my IDE.
Make my code changes and build on the local machine.
Make sure they do, in fact, fix the bug in question.
Run an SVN update on the local machine and repeat steps 1 and 2.
Run through the automated unit tests to verify that they pass.
If an automated smoke test is available, which automatically tests a lot of the system's capabilities, run it. Verify that the results are correct.
Then go to the build machine and run the build script.
If the project's configuration has changed, this could definitely break a build. Perform an SVN update on the build machine, whether the build script does that or not. Open the build machine's copy of the IDE, and do a complete rebuild. This will show you whether the build box has any problems that you have taken care of on your machine but not on the build box.
The suggestions to keep separate branches for each issue are also very good, if you can keep track of all of the issues you are working on.
First, use multiple working copies (a.k.a sandboxes) - one per issue. So, if you've been working on some complex feature for a while, and you need to deal with a quick bug fix on the same project, check out a new clean working copy and do the bug fix there. With independent working copies for each issue there is no confusion about which changes to commit from the working copy to the reposistory.
Second, before committing changes, always perform the following three steps:
Buld the software.
Run a smoke test (does it start and run without crashing).
Inspect the changes you're checking in by diffing your changes against the baseline.
These should be repeated after any merge operations (e.g. after an SVN update).
At my workplace, the safety net for this is peer review. That is, get someone else to build, run, and reproduce your solution on their machine, on their view.
I cannot recommend this enough. It has caught so many omissions, would-be problems, and other accidental pieces of junk to make it a valuable part of the process. Not to mention that the mere knowledge that you have to place your work in front of someone else before having it go on to the main branch means that you raise your own quality standards.
In the past I have used branching in Clear Case to help with this issue. The process I used is below. I've never used SorceDepot so I do not know how this can be adapted to work with it.
Create a branch for the bug fix
Code all changes on the branch
Code Review
Merge to stable branch in a different view (the different view is important)
BEFORE checking in: compile, test, and run
Check in code to stable branch
By creating the branch and then merging the changes to a different view (I use Merge Manager to do the merge) any files that were not included or checked in immediately cause issues. This way everything gets tested as it will be when checked in on the stable branch.
The best thing to avoid your problems, is to use hooks, that are provided in most SCMs (they are for sure in SVN and Mercurial, and I believe they must be in other advanced SCMs). Attach unit tests to the hook and make it run every time someone checks code in - exactly before it is checked in. This way you will achieve two things:
code in SCM repo will always pass the tests,
you won't make most simple mistakes, because they should be easily detectable, if you have decent test suite.
I like having Tortoise plugins for Windows Explorer. The file icons are all badged with committed, modified or not added icons making it very easy to see what status the files are in. I also enable the meta data for Modified so I can sort changed files in the list (Details) view, where they bubble to the top so I can see them.
I bet there is a Tortoise* plugin for your SCM, I saw one for Mercurial and SVN (and CVS, ugh). I really wish Mac OS X's Finder would accept plugins like Tortoise, its so much easier than having to pop open a dedicated app most of the time.
Get someone else to go through "every" change "before" you check in the code.
This may be somewhat obscure but I've been happily using Eclipse + Perfoce/P4WSAD for over a year now and have thus far been unable to figure this out myself. I often start a build and let it run in the background while I continue to edit source files. The problem occurs when I try to edit a file that is not checked out from perforce. In this case, eclipse pops up a modal dialog box that forces me to choose between either canceling the build or canceling the check-out operation. So usually I just cancel the build, check out the file, and start the build up again, but this is very time consuming. Is it possible to get eclipse to allow check-outs during builds?
I don't know, but you may want to check with Perforce on this (as this might be something specific to their plugin rather than something in the team su8pport), I never have this problem with SVN or CVS (though maybe my builds are not big enough). Also from what I understand the first generation Perforce plugin had major problems, but they have a new one that's much better. You should make sure you are on the new one.
A simple solution (although it can be disk-space consuming) is to have a building branch on which you merge any of your recently committed development (simple merges with no conflicts: you overwrite what is on the build branch).
Another eclipse project references that build branch sources and builds it whenever you want, while you edit the sources of your first original project.