Set up of directory

stefanks
stefanks
Sorry if this has been discussed but I am seeing or reading multiple ways of handling directory structure and how it is used. For instance, with my last repository, I set it up like this:    V1.0 - would be production copy - never work in directly, always make separate wc's  V1.01 - Development - Working copy, bug fixes  V1.1 - Development - Working copy, next phase      But it seems like it is common for it to be set up like this when using svn:    trunk - V1.01 - Working copy bug fixes or small enhancements  branch - V1.1 - Development - Working copy,next phase  tag - V1.0 - Production or version release    Is this a somewhat accurate picture? This is very simplistic and I know that there are a lot of variables that need to be entered into a true representation.    Thanks...  Stefan

Last updated

(ode$linger
(ode$linger
Sounds like what you're asking is what is most common. I don't think there's any way to know what's most common. "trunk" could mean any number of things to any number of people. Sometimes it refers to a stable line, other times it refers to the line that everybody commits into. These are conventions to help you determine what you want to do with your own...
JNiven
JNiven
Hi stefanks    It's accurate, but not compulsory. If your users are more familiar with your system, then SVN will accomodate it. For what it's worth, we use a "trunk" and "branches" system, but rename "tags" to "builds" (since we only ever tag a tree when it's built).    "trunk" is useful if most new development takes place there, but this isn;t always the case. Historically, we've done development in branches (though not in "branches", if that makes sense) then merged new code out to other branches. We're moving away from that towards development in "trunk" (as we move off one SCM system to SVN), and our new approach is an amalgam of our own SDLC and a more "trunk-tags-branches" system with most development in trunk.    Long story short - it's a widely-used convention, but SVN is highly adaptable.    Cheers  John
stefanks
stefanks
I figured as much because of the documentation that I've read. I was just wondering if there was a community based best practice. Kind of like saying, you can do it any nobody of ways but the standard is this way.    Thanks for the help.    
(ode$lingerSounds like what you're asking is what is most common. I don't think there's any way to know what's most common. "trunk" could mean any number of things to any number of people. Sometimes it refers to a stable line, other times it refers to the line that everybody commits into. These are conventions to help you determine what you want to do with your own...
stefanks
stefanks
We are switching to an Agile methodology with sprints being fairly quickly developed so a working copy should not be a problem. The svn box is set up and I have been playing with it for about 2 weeks. I am getting ready to wipe the OS and reinstall. I plan to keep the trunk as the main development and branch only if it is really needed (to keep the development team working).    The one problem that I have encountered is the merge from working copy's. I have not had a ton of success using subversive so I mostly of done it from the linux box and it a pain there. I am downloading 1.5 so I hope that the merge tool is better.    Thanks for you help.  Stefan    
JNivenHi stefanks    It's accurate, but not compulsory. If your users are more familiar with your system, then SVN will accomodate it. For what it's worth, we use a "trunk" and "branches" system, but rename "tags" to "builds" (since we only ever tag a tree when it's built).    "trunk" is useful if most new development takes place there, but this isn;t always the case. Historically, we've done development in branches (though not in "branches", if that makes sense) then merged new code out to other branches. We're moving away from that towards development in "trunk" (as we move off one SCM system to SVN), and our new approach is an amalgam of our own SDLC and a more "trunk-tags-branches" system with most development in trunk.    Long story short - it's a widely-used convention, but SVN is highly adaptable.    Cheers  John
JNiven
JNiven
Hi stefanks    I've done most of my merging (SVN 1.5) using either TortoiseSVN or the command-line, but if you're using Eclipse you might want to check out CollabNet - they had a merge-tracking Eclipse plug-in for SVN 1.5. It seems to have disappeared, but I suspect they've renamed it and formally released it now SVN 1.5 has been released.    SVN 1.5 definitely makes merging easier as you don't need to worry about tracking previous merges yourself.    Incidentally, in the long-term we're hoping to move to a more Agile approach (we use Agile already for our Java work), and that's part of the reason for us using "trunk" and "branches" in SVN). All of this is speculative as we're still on the old SCM system until the end of the year...    Cheers  John

1-6 of 6

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.