|
| [WX19] SCM - Best Practice |
| Iniciado por guest, 08,nov. 2014 11:33 - 6 respuestas |
| |
| | | |
|
| |
| Publicado el 08,noviembre 2014 - 11:33 |
Hi,
we are 2 developers and starting now with the SCM. Our SCM server is located in the company. If we both are in LAN it should be work as expected.
But from time to time we are not able to get online (driving by train). What should we do then ? I saw an option "Remote work". If I choose that both of as can work without connection to scm. But how we can merge the results together ?
It look like that must be manually or I overlooked something.
What is the best practice for that ?
And what is the meaning of "Branches" ? I don´t understand that ... |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,noviembre 2014 - 18:20 |
Under "Remote work" in the SCM ribbon, there is a "Reconnect and synchronize".
Then if you want to be sure you are both up to date, you can use project compare and both have checked everything in.
We also are only two developers and this usually works well. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,noviembre 2014 - 19:02 |
Hello Michael
The branch option is supposed to allow you to fork the project and change things in specific windows and reports etc but still use the bulk of the project as a base - good luck with that.
Be aware that in my experience the project comparison does not work for large projects.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
| Publicado el 11,noviembre 2014 - 10:55 |
Hi Michael,
I have been using the Branch feature of the SCM for over a year now (WD18) with very few problems. (project size ~250 windows).
We use it to fork the code before testing and eventual release to production. Any changes we make in the forked version can be merged back into the main version of the project. This means the other developers can carry on working on the main version of the project without affecting our forked version that is being tested.
Once the forked version is ready for production, we merge all the changes from testing back into the main version. This process works pretty well for us but it might not be as quick as the 'remote work' option.
Thanks
Ned! |
| |
| |
| | | |
|
| | |
| |
| Publicado el 11,noviembre 2014 - 11:23 |
Hi Ned,
>Once the forked version is ready for production, we merge all the changes from testing back into the main version. This >process works pretty well for us but it might not be as quick as the 'remote work' option.
Run this merge process automatically ? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 11,noviembre 2014 - 11:35 |
Hi,
Quote
Run this merge process automatically ?
This is a manual process. You can choose which forked version you want to take changes from and compare each changed item.
You can merge the whole window or report etc, or just the individual lines of code that have changed. If both developers have made lots of changes in the forked branch and the main version, this can become quite tricky, so I merge little and often to keep it simple.
Thanks
Ned! |
| |
| |
| | | |
|
| | |
| |
| Publicado el 11,noviembre 2014 - 22:27 |
Ok, we test something with strange behavior:
Developer1: Is online, he checked out window1, then he changed something
Developer2: Is online, he choosed "remote work", then he is offline and changed something in window1
Developer2: He comes back to LAN and connected, he choosed "sync", he is now online, his Window1 is checked out at his computer (even Dev1 has never checked in his window1)
After all, Dev1 and Dev2 are both online with different versions at the local machines. If Dev2 choose "get the newest version" he loose all his (offline) work and gets the window1 from Dev1. |
| |
| |
| | | |
|
| | | | |
| | |
|