Bob,
Thank you for the concise email. I am glad we have this email list to discuss and learn for growing skills and developing valuable contributions. I need to take time and digest all you have shared with tagging, as I do not have a test system to play and break and recover as part of the learning process. Furthermore, I am still not confident in my new kernel performance. I do not want to be juggling questions to know if SVN, my new kernel, or my lack of understanding is causing a barrier to achieve my goal when I am working on a production system such as our SVN system. I will svn copy the version 2.0 branch to trunk after svn delete of trunk. That will get us published for this weekend. We are already 2 months in publishing behind due to my personal illness holding up our release efforts. Then, I can do the emailing of the release, breathe a bit, and then look deeper into the tagging activities you identify we should pursue. I agree with the benefits you have identified with tagging. I simply need to think about how to best tag, then plan, then test, then do the said tagging. Again, thank you. I will be in touch in the future after I catch up from being behind in all activities cause by illness. Thank You, Stephen H. Dawson (865) 804-3454 http://www.linkedin.com/in/shdcs On 04/22/2016 06:39 PM, Bob Proulx wrote: > Hi Stephen, > > Stephen H. Dawson wrote: >> Thanks for the reply. Some clarification and questions from your >> response to me. > Stephen and I had a private exchange and with permission I am moving > this part back to the mailing list. > >> trunk directory: >> I believe I have miscomprehended the purpose of the trunk directory. I >> understood the purpose of the trunk directory is for a user to get the >> latest finished work. I now understand you telling me this is the >> directory of the latest development work. Am I correct in this new >> understanding? > First let me say that there is no single right answer. Books have > been written about different ways of doing this. Which makes it > harder in many ways. Some people like things one way. Some people > like things another way. > > But there are conventions that make life easier for everyone. One of > the expectations that I have is that if I find a project and check out > the trunk then I will get the latest development branch of the > project. The trunk directory in subversion is just a name. But it is > also by convention the main trunk of development. Trunk as in the > tree analogy with everything starting at the root and splitting off > into branches from there. The main trunk is the main part of the tree > of history. It usually shows the entire history from start to finish > unless there are intentional disturbances along the way. > > The workflow I prefer is that when a stable release branch is desired > that the release branch be created for the purpose of maintaining the > minor changes needed on that release. If development has been > proceeding on the main trunk then copy the main trunk off creating a > release branch. I usually only have the trunk or the branch checked > out at any one time. Therefore, for me, I will need to use the URL of > the repository. The URL can be seen using the svn info command. I > will use "foo" as a placeholder for the real project name. > > svn info > ... > URL: svn+ssh://svn.savannah.gnu.org/foo/trunk > ... > > For the purpose of discussion I will store it away into a variable so > that I don't have to type so much. I might do this on the command > line. Or I might just cut-n-paste it in. The long URL is a little > tedious. > > url=svn+ssh://svn.savannah.gnu.org/foo > > I can now use "$url" for a shortcut. > > svn checkout $url/trunk foo > cd foo > > And I can then create a branch using the url to manipulate the > repository directly without regard to the local directory working > copy of checkout files. > > svn copy -m "Create stable release branch" $url/trunk $url/branches/foo-3.2 > > Having created it then I can switch my working copy over to it. I > didn't check out everything, just the trunk. So for me to work on it > I need to switch my local directory over to it. > > svn switch $url/branches/foo-3.2 > > You can use 'svn info' at any time to see what the local working copy > is attached to. I do that often. If I come back to a directory after > having been away I usually start by going 'svn info' to look so I will > know what state things are in. And then almost always 'svn status'. > > Now that I have switched onto the branch I can make changes there. I > can make releases on that branch. But hopefully only minor changes as > befitting a stable release branch. No API changes. Nothing like > that. But small portability and bug fixes are perfect. > > [[ > You might want to read this article. This is again a religious > topic. Some people like it one way. Others like it a different way. > This matches with what I like and therefore I will reference it. > > Semantic Versioning > http://semver.org/ > ]] > > Back to the branch work in the working copy. We switched to the > stable branch using the 'svn switch $url/branches/foo-3.2' command. > The working copy should always be clean. Use 'svn status' to see. We > can switch branches as needed. We can switch back to the main trunk. > > svn switch $url/trunk > > Or I often have two directories. > > mkdir $HOME/src/foo-stuff > cd $HOME/src/foo-stuff > svn checkout $url/trunk foo-trunk > svn checkout $url/branches/stable-3.2 foo-stable-3.2 > > Instead of switching back and forth this way I can keep two > directories dedicated to each purpose. It can be much less confusing > that way. > > Always remember to update often! Any change to any part of the > repository increments the top level version number. That is the > "Revision:" field in the 'svn info' output. > > svn update > > I did a lot of talking about creating a release branch above. But > many projects keep things even simpler. Many projects use a single > development trunk and release from it. It is a best practice to > keep the main trunk always in a releasable state. If it is always in > a releasable state then it is easy to make a release simply by tagging > it appropriately. No need for any branches at all! > > This is important so I will emphasize it. If your main trunk is > always in a releasable state then it is easy to make releases. > >> I understood the purpose of the trunk directory is for a user to get >> the latest finished work. I now understand you telling me this is >> the directory of the latest development work. Am I correct in this >> new understanding? > I repeated the above since I wrote so much already since then. There > is no right answer. Many people like different things. > > But let me say this. With software it is rarely a "finished work". > And therefore the main trunk goes on and on. > > There is a maturity to it however. Often software will need little > maintenance over decades. That's okay. Or it might have rapid > development all of the time. And it may or may not have a stable > release. As the maintainer you get to choose the course of > development you want to use to work with it. > > I am not familiar specifically with remote control but it appears you > are making an archive of 1.1 and not expecting to make any more > changes to it. That sounds perfect for tagging. I don't think it > needs a branch. I would simply tag it by making a copy of it to the > tags directory. If there is need to revive it later then an active > branch could be made of it. It will exist available for anyone to > checkout in the repository. > > svn copy -m "Tagging release 3.2" $url/trunk $url/tags/foo-3.2 > > If others on the mailing list would like to share their favorite > operating work flows with us that would be great. I know I would be > interesting in the sharing of the ideas. > >> [svn del trunk]: >> I am not clear. Would this syntax not kill all history of the trunk >> directory? If so, this is not good. If not, then I will use the syntax. > The history will always be there. It is always available to browse. > For one it will always be associated with the new branch that was > created to host it. After the copy to the branch you can view all of > the history as part of the branch. > > svn copy -m "Create stable release branch" $url/trunk $url/branches/foo-3.2 > svn switch $url/branches/foo-3.2 > svn log | less > ...browse all of the history... > > It looks to me that branches/Version2.0 has work toward your newest > main trunk development. It has history that goes all of the way > back. You mentioned wanting to make it be the main trunk. That seems > reasonable at this point. It has the history of everything that went > into that code base. After moving it from the branch to the trunk it > will continue to have that history in the trunk. My suggestion: > > svn update > svn del trunk > svn move branches/Version2.0 trunk > svn commit -m "Moving branch to main trunk for continued > development." > > The "svn del trunk" looks scary but it can't actually delete svn > history (more on that in a moment) and this is just to prepare the way > to move "branches/Version2.0" over to "trunk". > > [[ > Subversion never actually deletes history. Even if everything were > deleted (please don't though) it all would still be in the history. > It is just more difficult to browse. If everything were deleted > then to access it one needs to specify the subversion syntax of a > version number when the files did exist. By specifying a "revision > specifier" you can check out the previous version which had the > files that were later removed and see them. That svn docs describe > this in detail so I don't want to here. Just let me say that it is > easily gotten to even if it has been removed from the current > version. > ]] > >> [svn move] >> I do not want to move. I want to have a static copy of the release until >> we get a better handle on SVN work as project team. > A static copy sounds like a tagged copy to me. Tags should be created > exactly once and then never changed again afterward. This sounds > perfect for tagging. > > If you write a little description of what you are wanting to > accomplish with enough background for us to understand what the goals > are then we on the mailing list could suggest things to do. I think I > know what you want but I am not sure. And here it appears I don't > quite understand yet. > >> Release Announcement SVN Path: >> I am fine with announcing the path to the latest and greatest release is >> in the branch section. What svn syntax should I provide in the >> announcement of the newest version? >> >> svn://svn.sv.gnu.org/remotecontrol/branches/Version2.0/ >> >> Is this correct? > If you want to the world to checkout a branch that is okay. I suggest > this syntax in that case. > > svn checkout svn://svn.sv.gnu.org/remotecontrol/branches/Version2.0 > remotecontrol-2.0 > >> Tags: >> Yes, we need to use tags. We as a team are not to the point of >> accomplishing this level of repository management. I hope we will be >> there soon. > Tags are very lightweight. They are easy to create. > > svn copy -m "Tagging release 3.2" $url/trunk $url/tags/foo-3.2 > > Every release should be tagged for future reference. This can be done > at any time the release version is finalized. Today. Next week. > Next month. It's never too late. > > It can be too early however. Tagging a "candidate" as a release > before it has actually released is basically the same as releasing it > in my strict view of the world. Because even though subversion allows > you to remove and recreate the tag on a later version that creates an > ambiguity. Did someone pull the first release of 3.2 or the 3rd > release of 3.2? Shudder! I once saw a project make *FOUR* releases > of exactly the same version number. That's bad. If this happens to > you don't try to salvage a number. There are lots of numbers. We > aren't going to run out. Simply move on to the next number and do not > worry about it further. > > Additionally I don't like projects that release purely from a version > tracker. I am old school and like to see an actual release bundle of > files that can be put onto the mirror site and propagated. Because > not everyone has a live network connection. Even if most of the users > do there will be many that do not. Philosophically I want to make > free libre software available to everyone that wishes to use it. Even > if they are on a space station or at a research hut in Antartica or a > small village in the developing world. High bandwidth networking is > not universial. Making release bundles makes the software available > to everyone and I think is a very important part of project > maintenance. > > Whew! Sorry for writing a novel. Hope this discussion helps! I also > welcome constructive discussion about this from other members of the > mailing list. > > Bob > >
