We are using Subversion and Subclipse on a J2EE project. I am well-versed with SCM, but am somehow missing a step with SVN.
What I want to do is pull the latest code from trunk (HEAD). Make my changes locally, then commit them to a branch (using Subclipse's Team >> Branch/Tag... menu item).
I can specify the branch/tag name and that I want the source to be my working version, and all is great. I get a branch with the handful of files that I changed.
Now comes the problem... other developers need to work off of this same branch, possibly modifying my code, possibly changing other files that I did not version into the branch/tag. The goal is for them to pull the latest from the branch/tag into their workspace, so they have the latest codebase plus whatever changes the branch/tag contains.
The problem is when you do this, there is no single entry point from which to make the pull. People have to pull latest from the trunk, then pull from the branch/tag, and if I have 5 files in the folder I am working in, but only one was committed to the branch/tag, then updating locally from the branch/tag results in just one file in that folder.
Sorry if this is convoluted, but I must be missing something if I can't work in such a common way... I hope. I did see something about Subclipse not being change-set aware, and am hoping that that is no what is preventing me from doing this.
Can someone illuminate or re-direct me to an alternative solution?
Thanks a million!
"It is our choices, much more than our abilities, that make us who we are."
- Albus Dumbledore
It sounds like you're attempting to store the changes and only the changes in your branch. That's not how it works. Copy the entire trunk project to the new branch (subdirectory under the branch directory).
Subversion isn't like CVS. CVS copies actual files. Subversion only copies the view of the files, including the information that indicates the differences between the branch and the trunk.
So if I wanted to work on a private branch of version 1.3.4 of the project, first I'd look in the tags directory for version 1.3.4. You should have created that as a snapshot of the trunk when you created the 1.3.4 release. To make a branch, I'd use Eclipse to check out the tagged 1.3.4 release as a project, then use Eclipse (subclipse) to immediately make a branch of that release. Let's say I have my own branch folder. Maybe I'd create a branch whose path was branch/tim/V1_3_4_mods.
Finally, after having created my Subversion branch, I'd tell Eclipse to start working with that version. That would mean that as I committed working changes to the project, they'd be applied to my branch archive, and not the archive of the 1.3.4 tag or the trunk. By doing that, I'd have backups of my work without polluting the trunk or the 1.3.4 tag release, and I'd be set up for the next step - merging.
Finally, I'm done and I want to merge my changes into the main trunk. I'd then use the Subclipse tools to merge my branch to the trunk.
An IDE is no substitute for an Intelligent Developer.
Joined: Oct 21, 2008
Thanks for the explanation. I think I was trying to get eclipse to perform in a way that it isn't built for.
Here is what I am trying to accomplish, and how our process works:
Our creative department typically initiates a new project (a mailing where they begin designing the HTML content). Developers then do the coding and integrate the creative.
We have had problems with files being left out of builds due to poor process, so I have suggested that we make each mailing project it's own branch (or tag) in SVN. This means that the creative team needs to forge the new branch/tag when they start on a new project, and the developers need to make sure that they are pointing to the newly created branch.
We are trying to avoid copying the entire eclipse project as it contains numerous mailing "projects" of this nature, and we do not want the overhead in terms of time or space to copy the entire thing just to create and modify the contents of two discreet folders. This is why I was trying to use a "changeset."
So now, I believe what we should be doing is:
Creative Team pulls latest from HEAD of the trunk
Creative Team then creates a new branch, from the two aforementioned folders, with the name of the mailing project under the branches folder in SVN
Creative Team does their work and commits to this branch
Development Team pulls latest from HEAD of the trunk
Development Team then points the two folders being worked on to the branch versions***
Development Team does their work, committing to this branch
Once development in the two folders is complete, the branch is merged into the HEAD of the trunk, QA'd, and released
Does that sound reasonable, or is there a better way to do this? Remember we are trying to avoid branching the entire project.
*** What happens when the two folders are newly created? Developers will not see them when they pull from HEAD on the trunk...
Well, I may not have it all clear yet, but this sounds like the kind of thing you get when you have a master project with sub-projects.
There's nothing magic about "trunk", "tag" or "branch". They're just a convention. Each of them is a folder, and Subversion maintains versioning on each folder in the project, both great and small. The idea is that you can get a snapshot of the subversion "filesystem" for any point in time you like. You don't normally check out root of a Subversion project to create an Eclipse project. Instead you check out the trunk or one of the branches or tags. However, you can check out any subtree you like, as long as it makes sense as an Eclipse project.
Just to clarify, an Eclipse project is a collection of files managed as a unit by Eclipse. It doesn't have to map to an entire Subversion project. So it's perfectly legal to have a Subversion structure like: BigProject/trunk/BigProject/src/webapp/html/accounting where all your accounting HTML pages are located in the BigProject Monster Web Application. And to check out that folder as an Eclipse BigProjectAccountHTML project (the name I gave it when I created an Eclipse project on my machine), which is then checked into Subversion as a branch: BigProject/branch/tim/AccountingEnhancements/html
So if you can come up with a good setup for a list of just the sub-projects needed for work, you can keep from having to check out everything whether you need it or not.
It's all based on folders. Subversion+Eclipse doesn't support mix-n-match at the file level, but as long as the folder setup works, then you should be able to come up with something usable.
Joined: Oct 21, 2008
Hi Tim (et al),
Thanks for the info and input, I really appreciate it.
Sorry to be obtuse, but I am still stuck trying to figure out some sort of workable process for this mess.
Does what I outlined in my last post seem to work or even be effective?
How do I deal with the folders newly created in the branch when the developers need to pull them down to begin working inside of them?
Can you give me your "best-practice" for accomplishing this if my idea is lame?
Thanks a million. Sorry to lean on you, but I have been banging away at this for a couple of days now and I don't feel any closer to a solution.
Joined: Oct 21, 2008
Apologies if this is coming while you are writing a response, but I think I have a solution (giving due credit, one of my developers came up with this, not me ).
Everything I described works for all of us, except it is too labor-intensive and too technical for our creative team. So we are going to refactor our folder structure (fortunately all adjustable from XML config files), so that the creative team's work is encapsulated in a completely separate folder, which will be a peer of the "mailing" folder shown above.
We will then create a project of that folder which creative will use as their development basis, and when the devs forge a new branch, the first thing they will do is switch the folder for the creative to that development branch. Everyone is in sync, creative is minimally impacted, and everything resolves nicely when we merge to HEAD for release.
PLEASE feel free to shoot holes in this, say it sucks out loud, or offer a completely different solution if there is a better/more traditional/cleaner method.
And again, thanks for the help. Sometimes just talking through the problem with someone is immensely helpful in solving the issue.