Skip to main content

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