I know that it is best practise and case for trunk NOT to be unstable or left unusable, but I think this is an acceptable time and place for it!
Even though it is NOT being done!
If it were to be left unusable for nth amount of time, then it might have been best in a branch, but as we can see, Nick is right on top of it and in constant control of it...
Rob G. Healey
Rob,On May 26, 2012, at 10:38 PM, Rob Healey wrote:Dear John:
You are correct that people do all kinds of different things for all kinds of different reasons!
Sometimes it makes sense and sometimes it does not!
I was just going off the fact that Brian didn't when he was doing GEPS008 things! There were a few times when he moved a large amount of files if I remember that far back???
What another developer might have done or not done in the past isn't really germane. Doing a major change in a branch instead of on the trunk is now considered a "best practice"; it might not have been at the time you're remembering.On Sun, May 27, 2012 at 12:08 AM, John Ralls <firstname.lastname@example.org> wrote:
On May 26, 2012, at 6:57 PM, Rob Healey wrote:
> I do not understand the need for a new GEPS branch for this as there has NOT been any need for one in the past work done that Brian has done either...
It's not a "need" per se. It's just common practice when one is working on something potentially disruptive, and lots of file moves certainly can be. Heck, some people open a branch for non-trivial bug fixes.
Did you mean for this not to be on the list?
Yes, I meant for it to go to you only! I didn't want to seem as if I were bullying you in front of everyone!
I know that I have made mistakes in the past, of whom my audience was, when I made certain comments and embarrassed someone when it wasn't meant...
Yeah, me too.
I know that this type of work can be disruptive as there are so many different things being done at once, but I do believe that it might be very complicated or hard to get things back into the repository afterwards!
It never leaves the repository, the work is just kept separate from the part that everyone else is working on until it's fully tested. With subversion, merging can be a pain if trunk has seen a lot of changes in parallel with the branch because it doesn't (or rather didn't before svn-1.7) handle multiple merges very well. That's one of the major advantages of git over subversion: It's easy to bring the branch up to date before merging it back in. It's also easy to do multiple merges from the branch back to trunk (which is usually called "master" in git repositories). But for a set of changes which is entirely renames, there isn't likely to be any difficulty merging unless someone else does a rename on trunk while the major work is in progress on the branch.The advantage of doing major changes on a branch is that tt allows the developer working on the branch to commit partial changes that make a nice "chunk" that's easily described in a commit message, but which might not leave the branch in a buildable state. Nick's comment that "Hopefully I will leave trunk in a working condition after each commit" (4FC116C5.email@example.com,17:45 Z 26 May 2012) was an indication to me that a feature branch is indicated.Regards,John Ralls