Timeline for Is it a good idea to lock svn
Current License: CC BY-SA 4.0
17 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 15, 2020 at 8:55 | comment | added | Flater | "Every developer has his own branch and does his development on this branch." Just to be clear, are you advocating a branch per developer, or per change/feature (which generally is assigned to a given developer)? If I, as a developer, finish my task and start another, do I create a new branch or do I repurpose "my" branch from the first task? | |
Jan 14, 2020 at 14:41 | answer | added | gsl | timeline score: 0 | |
Jan 8, 2019 at 15:35 | comment | added | Doc Brown | @CecilWesterhof: what you described would not end in a failed "merge into trunk", but in a failing integration test after a successful merge, right? However, I think the process above approaches this from the wrong angle. In those rare case you have conflicting changes which make it into the trunk, on each side of the globe there should be someone able to fix the problems. That is the idea of "shared code ownership". Reviews, especially cross-site reviews, will help to get the team to that point, of course. | |
Jan 8, 2019 at 15:29 | comment | added | Cecil Westerhof | @DocBrown In hindsight I think I was to careful. Probably there will be at most 10 developers. When they are spread over the globe then is the chance the will get into each-other way slim I think. But better to careful, as not careful enough. ;-) | |
Jan 8, 2019 at 15:00 | comment | added | Cecil Westerhof | @DocBrown The idea was that when two developers would commit at almost the same time, it would be possible that both individually pass the integration test, but combined do not and that by locking only one could commit and you would not get this situation without the second developer getting a long delay. But the way of working has changed: now there is always a review. So with this new workflow (which I prefer) I do not think it opportune to do it like this any-more. | |
Jan 8, 2019 at 14:12 | comment | added | Doc Brown | I miss the point of your idea of locking the SVN server - if I got your process right, when a "Merge back into trunk" fails, noone else except the person who tried it does not get his/her code integrated, so noone else is directly affected. | |
Jan 7, 2019 at 21:00 | history | tweeted | twitter.com/StackSoftEng/status/1082381490560880648 | ||
Jan 7, 2019 at 9:30 | answer | added | Bart van Ingen Schenau | timeline score: 7 | |
Jan 7, 2019 at 8:34 | answer | added | Lazy Badger | timeline score: -5 | |
Jan 7, 2019 at 7:00 | history | edited | Cecil Westerhof | CC BY-SA 4.0 |
added 113 characters in body
|
Jan 7, 2019 at 6:57 | comment | added | Cecil Westerhof | @DocBrown I would like to use Git, but I am overruled on that. So for the moment I need to work with svn. I will add that to the question. | |
Jan 7, 2019 at 6:44 | comment | added | Cecil Westerhof | @max630 Is the description clear now? If not what should I add? | |
Jan 7, 2019 at 6:43 | history | edited | Cecil Westerhof | CC BY-SA 4.0 |
added 1795 characters in body
|
Jan 7, 2019 at 6:33 | comment | added | Cecil Westerhof | @DocBrown It is a ba idea. Why? | |
Jan 7, 2019 at 6:33 | comment | added | max630 | Please clarify when do you mean by "merge" and "commit". What do you merge and where to in each case | |
Jan 7, 2019 at 6:31 | comment | added | Doc Brown | It is good that you ask here, since your approach seems weird. However, I am sure you will get downvotes from people here who don't understand the downvote button is not for bad ideas, only for bad questions. Besides that, someone will writea good answer along the lines of "use Git & Pull Requests". | |
Jan 7, 2019 at 6:24 | history | asked | Cecil Westerhof | CC BY-SA 4.0 |