In some earlier postings I concluded already that Source Control still seems to be a crippled system which does not allow you to include a shared project within 1 git and is also error prone because of the endless range of VS errors. After multiple installations of a credential manager and a couple of tricks we are now able to commit changes without errors. But when I choose Pull in VS I get the following message:
Cannot pull because there are uncommitted changes. Commit, stash, or undo your changes before retrying. See the Output window for details.
What I expected is that Visual Studio would show me any conflicting changes and let me decide if I wanted to keep my own changes (and commit these) or apply the changes from the Bitbucket Repo. But it seems that the only thing I can do is roll back the changes. For that I opened SourceTree (there seems no way to do so in VS) and saw that all "changes" I had were capitalization of keywords. So for 4 programs I had to select Discard before I could select Pull. Not in VS: as soon as VS notices that the source is changed, it changed capitalizations again giving the same error.
So in short: I can now apply source code changes from others but it is hardly more sophisticated than the VO method were we mailed changed .prg/.mef or .aef files and imported these.
Is there anything I missed in VS or is this all there is regarding source control?
Dick
Source control & changes by 2 users
Source control & changes by 2 users
Dick,
Git works with a local repository as well as a remote repository.
Before pulling changes from the remote repository you need to commit your changes locally first. After that you can pull the remote changes. These will be merged with your local changes and if there are conflicts you will have to take care of these in your local repository until you have a working build. Then you push the merged changes back to the remote repository.
So the normal order of things is:
1) Commit locally (or discard/rollback/revert the changes)
2) Pull from remote
3) Handle merge conflicts. Compile and test
4) Push back merged changes.
Git does know know that X# is case insensitive, so changes in capitalization are seen as changes and might cause conflicts.
And to be honest: VS does not change the case. That is the X# language service. It is therefore very important to coordinate these settings in your team.
We have planned to add support for .editorconfig so you can set the case for a project/solution in a file inside the solution which will then enforce the casing rules for all developers working with the same project inside VS. That should reduce the number of conflicts that are only case conflicts.
Robert
Git works with a local repository as well as a remote repository.
Before pulling changes from the remote repository you need to commit your changes locally first. After that you can pull the remote changes. These will be merged with your local changes and if there are conflicts you will have to take care of these in your local repository until you have a working build. Then you push the merged changes back to the remote repository.
So the normal order of things is:
1) Commit locally (or discard/rollback/revert the changes)
2) Pull from remote
3) Handle merge conflicts. Compile and test
4) Push back merged changes.
Git does know know that X# is case insensitive, so changes in capitalization are seen as changes and might cause conflicts.
And to be honest: VS does not change the case. That is the X# language service. It is therefore very important to coordinate these settings in your team.
We have planned to add support for .editorconfig so you can set the case for a project/solution in a file inside the solution which will then enforce the casing rules for all developers working with the same project inside VS. That should reduce the number of conflicts that are only case conflicts.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Source control & changes by 2 users
Thanks Robert,
Sounds logical, except that there does not seem to be a different way of committing locally or to Bitbucket. See the picture. After I discarded the capitalization changes (in Sourcetree) and pulled all changes which Kees committed earlier I would expect VS would not show me any "pending commits". And certainly not to Bitbucket cloud. I suspect that when I commit these 4 now, I change everything Kees programmed back to were we started with.
Dick
Sounds logical, except that there does not seem to be a different way of committing locally or to Bitbucket. See the picture. After I discarded the capitalization changes (in Sourcetree) and pulled all changes which Kees committed earlier I would expect VS would not show me any "pending commits". And certainly not to Bitbucket cloud. I suspect that when I commit these 4 now, I change everything Kees programmed back to were we started with.
Dick
- BBdbv.JPG (48.59 KiB) Viewed 292 times
Source control & changes by 2 users
Dick, this looks OK to me. The bottom one is the oldest commit and are your changes. The other 3 are your merges with the code from Kees.
When you synchronize with the remote repo then this should result in a merged copy of your changes and Kees his changes.
You can always review the changes for each commit when you open the history log for the branch and compare the various versions.
Robert
PS: I forgot to say: this image shows that you have already committed locally.
When you synchronize with the remote repo then this should result in a merged copy of your changes and Kees his changes.
You can always review the changes for each commit when you open the history log for the branch and compare the various versions.
Robert
PS: I forgot to say: this image shows that you have already committed locally.
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu