simple question on branching
We don't often use branching and/or merging based on the simple nature of our version releases with very little overlap. We have a longer ranging version - the next 7 months or so in progress. Since we are getting ready to deliver some file changes I'd like to use the trunk instead of a branch just because it's easier. There is a very little chance we would really need to release anything to the previous production level during these 7 months. If it came up I was going to just copy the tag to a branch and use that for development - and basically tagging it (or maybe even merging into the tag). Any reason that creating a permanent branch on the tree would matter -- i mean never merging it anywhere? I don't see what harm it would have really - but I just wanted to be sure in case I decide to branch from the production version of the trunk instead. Probably a silly question - but it's good to have input from others who branch and merge regularly. Thx for any help. If it matters - we are still on svn 1.4.3. KM
Re: simple question on branching
Thanks. My sentiments exactly. Never branch really - and... I probably will not branch for this either !! And yes... so far of course I have never changed a tag of the version released to the field and don't really plan to. I'll make another if necessary. Just trying to think ahead in case. --- On Wed, 11/3/10, David Weintraub wrote: From: David Weintraub Subject: Re: simple question on branching To: "KM" Cc: "svn-apache-users-list" Date: Wednesday, November 3, 2010, 10:36 AM On Wed, Nov 3, 2010 at 9:44 AM, KM wrote: > > We don't often use branching and/or merging based on the simple > nature of our version releases with very little overlap. > > Any reason that creating a permanent branch on the tree would matter > -- i mean never merging it anywhere? I don't see what harm it would > have really - but I just wanted to be sure in case I decide to branch > from the production version of the trunk instead. Anyone will tell you that branching and merging is hell, and if you can avoid it, you avoid it. The standard is to keep branching to a minimum and only do it when necessary. There are really two main reasons to branch: Reason #1: You are about to do a release, and want to avoid developers twiddling their thumbs as you do a code freeze. Branching allows some developers to clean up the code on the branch and release from the branch while other developers continue working on the trunk. Reason #2: You are working on a new revision when a bug was found on an older revision, and you want to fix that bug before the new revision comes out. Of course, if you branched for Release #1, you already have the branch you need for that bug fix. Open source projects rarely branch. If you find a bug, they simply tell you to wait for the next release (which probably comes every few months). If you really must have the fix now, you grab either the trunk source code where the fix might already be implemented or the release source code and fix the problem yourself. Nor, do open source projects care about keeping developers occupied while they try to prep the code for a release. After all, they don't pay the developers, so they don't care if the developers have nothing to do. If you don't need to branch, then don't branch. I've worked on many projects which almost never branched and others that loved diagramming complex branching schemes. (Release 1.0.1 branched from the Release 1.0.X branch which branched from the Release 1.0 branch which branched from the Release 1.X branch.). I will tell you that ones that never branched had better development and fewer problems. So, if you don't need to branch, you're fine. And, if you do need to fix a bug on a release, you can always branch from the tag and fix the bug on that branch. (Or, you can find the revision that created the tag and simply branch off the trunk from that revision.) What ever you do, don't change your tags. Tags are suppose to be snapshots of what took place and should be absolutely stable. When the sun explodes into a fiery ball and destroys all life on Earth, any alien being who lands on the Earth's charred remains and finds your source repository should see the same set of files tagged as REL-1.0.1 that you did the day you created that REL-1.0.1 tag. -- David Weintraub qazw...@gmail.com
Advice on upgrading svn and moving to new server
I have svn 1.4.3 running on a solaris 8 server. I want to either upgrade this particular server to solaris 10, or move the entire thing to a new solaris 10 server, and also to upgrade subversion to the latest stable version (along with all of the dependencies of course... apache etc.) If I decide to use the same server I am now - what's the best thing to do ... upgrade the OS and then all of the packages and dump and load the repository? If I am moving - I assume I would set up the OS and packages on the new server including the new svn - then can I dump the repository and then load it on the new server - or just move the repository over and do the same? Unfortunately I upgraded to 1.4.3 a while back and haven't worked on this in quite some time. I apologize for stupid questions. I want this as easy as possible. Also has anyone ever used the webstack/glassfish SW and set it up for svn. Since I also use Mantis - the php would also be taken care of at the same time this way just curious. Thanks in advance for any advice. KM
RE: Advice on upgrading svn and moving to new server
Thanks I think. Not sure it helps with my original question. ... which i am sure i'll figure out by trial and error. Whether to updgrade to solaris 10 w/new server, install newer svn and dependent packages and then copy reppos from old server - dump it and load it. Or do I need to install and upgraded svn and repos on old server then copy to new server - etc - Since i am only at 1.4.3 on solais 8 and I want to be on Solaris 10 with svn 1.6.x I just wasn't sure how easy or difficult it all would be, and what the order of the tasks should be to make it the least effort and most efficient upgrade. Just wanted some advice about the easiest way to accomplish my task. Thx a bunch. KM --- On Thu, 3/31/11, Bob Archer wrote: From: Bob Archer Subject: RE: Advice on upgrading svn and moving to new server To: "Nico Kadel-Garcia" , "Daniel Shahaf" Cc: "Kevin Grover" , "KM" , "svn-apache-users-list" Date: Thursday, March 31, 2011, 2:51 PM > > On Wed, Mar 30, 2011 at 3:17 PM, Daniel Shahaf > wrote: > > Kevin Grover wrote on Wed, Mar 30, 2011 at 08:13:34 -0700: > >> When upgrading, mostly you can still access old repositories. > SOMETIMES > >> they will be silently upgraded in someways > > > > I don't know that the above sentence is correct. Can you give > > an example of a scenario when that happens? > > Working copies will be upgraded silently. A working copy is not a repository though. BOb
Upgrading/Moving SVN after exists on other server
I have an existing older installation of svn 1.4.3 on solaris 8. We are doing work on Solaris 10 now. To save time I wanted to install svn 1.6.x on the solaris 10 box and set up a new svn repository for this version of our project. My question is - if i do that how do I later move the existing repositories from the old server? can i just copy them in, or do i have to dump them and create empty ones on the new box and load them. Also I assume between 1.4.x and 1.6.x there are conversions for the databases? Eventually the entire solaris 8 will be migrated to Solaris 10 ... just don't have the resources or time now. thx - KM
package with everything you need for svn?
Does anyone know if there are all inclusive packages out there with svn and all of the other open source dependencies ... so I don't have to install (or compile/install) all the other packages one at a time? or at least a package to download and compile everything at once, together without downloading all of the individual pieces and working on them. i am going to be running Solaris 10 when I do this. I also want svn 1.5.x or later? Any info/help is appreciated. KM
Re: Branch issue
In my opinion this sounds more like a coding issue than a source control issue, unless I am misunderstanding you. I don't think svn should be used to control the contents of your files. You need to make the script generic so one version will work for all versions of RHEL. Then you may control one script with svn. There are probably plenty of shell programming mechanisms you may use to get the script to be more vanilla or generic and work on all RHEL versions. If they indeed need to be very different then you should control them separately. This is just my opinion though.KM From: Jan De Luyck To: users@subversion.apache.org Sent: Monday, May 4, 2015 8:14 AM Subject: Branch issue Hello folks, Perhaps a stupid subversion question, but one i haven't been able to figure out yet: I've got two scripts in the same directory, which are basically variants - one for RHEL6, one for RHEL7. Most of the content will be the same, with small changes here and there. The files are named according to the RHEL version. Unfortunatly the scripts have to be completely self-contained, so using modules/shared libraries/... is not an option. Ideally I'd like to only have to manage one script, and pull the changes into the second. But sofar I haven't figured out a way yet to do this. The only thing I thought of is moving both to a separate dir, and branching one from the other. Doesn't seem ideal though. Any pointers/ideas how I could tackle this? Kind regards Jan
