We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).
Related
We recently have moved from SVN to GIT, and until recently, the problems with the move were if not minimal, at least manageable.
Until a few weeks ago, we just had a single active 'master' branch, which was the old SVN trunk. But then, we added a branch to do a major upgrade while keeping the master available for bugfixes that could then be easily deployed.
The problem is that as soon as the different project team members started to check stuff in, the Eclipse (Mars 2 with EGit) Team Synchronization perspective started showing stuff as needing to check in that really didnt.
The first time I synchronized, a load of incoming changes came in (the blue arrow) which was unusual as I hadn't seen any since moving to GIT, - we just had to do a PULL instead - so foolishly I accepted them in. That ended up merging the changes we had put in the trunk with the branch, which we DIDN'T want to do.
Worse, even after pulling in those changes, they still appeared but now as conflicts, even though I accepted them and the files were identical. Nothing I can do (Mark as Merged, Overwrite, Commit...) gets rid of them.
Anyway, the most unhelpful problem is that now the Team Synchronization brings in hundreds (currently 825!) supposed changed files when I do a synchronize now. Many of these files are obscure ones that havent changed in years, and are clearly unchanged yet they show up. Trying to sift through the file list to find what I have actually changed is too much effort, especially as Eclipse helpfully refreshes the list with all the items I removed from the view each time I make any change!
So basically now I am resorting to GitKraken, which has substandard diff tools but at least shows an accurate view of what needs checking in. Why they decided on the Duplo-sized fonts that take up so much window space in the staging area I have no idea. And it's SLOW.
I now have a healthy dislike for GIT because its such a faff compared to SVN, although I acknowledge a lot of this is down to the GIT implementation in eclipse.
So, does anyone have any tips about how to get Eclipse to recognize that most of these files shouldn't actually be displayed? Am I missing some configuration somewhere? When I right click on the project in eclipse and do Team > Switch To, it correctly shows the branch Im working on, so why is it so inaccurate? Im using Eclipse Mars2 4.5.2 with JGit 4.6.1
Any tips appreciated.
For anyone else having similar problems with this, I sort of have an answer.
My answer is, that Im not sure what got it working, but my team synchronizing perspective now shows 99% the correct view. I clicked on various things with increasing desperation to get this to work and then some combination of the below in the Team Synchronizing perspective had the right effect:
In the Synchronize tab, select the down arrow next to the view type and select either Java Workspace (for the master) or Git Commits (for the branch)
Click the down arrow next to the Synchronize icon at the far left, select Synchronize and then Git, then select the correct destination (eg ref/heads/master) and then clic on 'Include local uncommitted changes in comparison'
Hopefully thats of help to someone.
I have Sparx EA setup with version control. Prior to checking in updates to my model I did a get all latest. But doing so has completely mangled one of my diagrams. This is particularly odd as:
The packages that contained the diagram and all the components in the diagram were checked out by me - so there is no way these should ever be updated the get all latest.
In any case I'm the only one who has ever worked on this model.
What appears to have happened is that that I refactored a large diagram into three separate ones, buy cutting and pasting some components from the original into new diagram, leaving the original with a subset of the original components. The get all latest seems to have re-inserted all the original components and connections back into the original diagram and even re-locating some of the components in the original diagram, leaving an utter mess.
Is there any way to undo the actions of what I can only assume is a pretty serious bug?
many thanks in advance.
No, you can not undo that unless you have a database backup. If you have not committed your work before, it's your own fault.
FWIW: Get All Latest is meant to be used in single distributed EAP files (or RDBMS remote to a central repos). It will erase all work and replace it with what has been stored in the VC system.
Edit: Although the help states
The Get All Latest command does not update any package that is checked-out (to anybody) in the currently loaded project; otherwise, any changes not yet committed to version control would be discarded
this may affect current diagraming work. The simple reason is that a diagram content can well rely on other packages being altered during a Get All Latest. It also depends on whether one saves diagram changes which are otherwise held in memory and can cause trouble.
Anyhow, there is no undo for Get All Latest for sure. Go into a dark chamber, cry out loud and start doing it once again. Just revert to an older commit first.
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.
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.
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.