 |
 |
Forking files in our repository by manually copying them into the users module and then checking in the forked copy creates a mess of things. There are then two copies of the same file, with no real connection between them in version control unless you did an 'svn cp' operation (which I presume was not done). All the log messages for work on the forked file then do not get attached in any way to the original file, so you have to look at both the forked and original copy to figure out which changes were made. Then presumably the forked file is copied back manually over the original (potentially clobbering any updates or fixes that've happened to that file since you forked which is a real concern). And let's say that the forked file is deleted when you're done with it. How do I easily use 'svn log' to see the changes that were made on the forked copy, unless I know that it used to exist at sometime? Since there is no real connection between the two files aside from their name, if the forked one is deleted, it is unlikely I could easily figure this out without knowing beforehand that you forked it. I could go on about this, but I think you get the point..... -----Original Message----- From: Nathan Baltzell [mailto:[log in to unmask]] Sent: Wednesday, May 27, 2015 5:00 PM To: McCormick, Jeremy I. Cc: hps-software Subject: Re: branch more Note that manual branching doesn't necessarily result in any instability, breaking, unwanted changes, nor incorrect svn logging, so long as the manual brancher is well aware of what is going on with the relevant files and committed to their obligation not to screw things up. Strong empirical HPS evidence shows that manual branchers are pretty good about this and that the instability problems we've encountered originate elsewhere. -Nathan On May 27, 2015, at 5:46 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: > Hi, > > I am generally concerned with all the changes flying around in hps-java trunk lately that most people are not using proper version control tactics to manage their work. We should generally be branching the code far more often in order to avoid making trunk very unstable, which it has been lately. In fact, I would suggest that every major JIRA item which requires more than a few lines of code get its own branch where the work is entirely isolated from trunk until it is completed. This might seem excessive, but it has advantages (listed below) and branches can be deleted after we are done with them. > > Branching has many advantages such as.... > > 1) Complete isolation of any potentially 'breaking' changes from trunk. Commits made to a branch do not affect trunk at all. > > 2) Complete isolation from you getting unwanted changes into your branch unless you merge them in yourself. You can manage yourself which trunk changes get pulled into your branch if some are needed. > > 3) The ability to make incremental commits to the branch to save your work periodically, which might make it unstable/broken, with no affect on trunk. > > 4) The proper accumulation of history/log files attached to the correct files/nodes in the SVN repo as you make commits. > > To branch from a copy of hps-java, assuming you are working on JIRA item HPSJAVA-1234 (just a dummy name) ..... > > $ cd trunk; svn cp ^/java/trunk ^/java/branches/HPSJAVA-1234 > > Now you can make a new Eclipse workspace for the branch.... > > $ mkdir workspace.HPSJAVA-1234; svn co > svn://svn.freehep.org/hps/java/branches/HPSJAVA-1234 > > Then switch to the workspace in Eclipse and use the usual 'Import' menu item to load all the Maven modules from the 'HPSJAVA-1234' directory into that workspace. > > Now you have an entirely separate workspace for that branch to keep it separate from your work on trunk. > > Then when you're ready to merge back in to trunk.... > > cd trunk; svn merge ^/java/branches/HPSJAVA-1234 . > > What I've described works well in terms of managing changes and working on tasks in JIRA. > > In particular, whatever you do, please *do not* manually copy/fork files from the hps-java modules into your user area and then modify them there with the intension of copying them back over the primary file at some point. This has all kinds of problems with it that are avoid by using proper branches for your work. > > Thanks. > > --Jeremy > > ###################################################################### > ## > Use REPLY-ALL to reply to list > > To unsubscribe from the HPS-SOFTWARE list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1