aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes Managing changes in SVN/Subclipse Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Managing changes in SVN/Subclipse" Watch "Managing changes in SVN/Subclipse" New topic
Author

Managing changes in SVN/Subclipse

Christopher Burns
Ranch Hand

Joined: Oct 21, 2008
Posts: 33
Hi all,

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!

Chris


"It is our choices, much more than our abilities, that make us who we are."
- Albus Dumbledore
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15662
    
  15

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Christopher Burns
Ranch Hand

Joined: Oct 21, 2008
Posts: 33
Hi Tim,

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...

    Thanks a million,

    Chris



    Tim Holloway
    Saloon Keeper

    Joined: Jun 25, 2001
    Posts: 15662
        
      15

    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.
    Christopher Burns
    Ranch Hand

    Joined: Oct 21, 2008
    Posts: 33
    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.

    Cheers,

    Chris
    Christopher Burns
    Ranch Hand

    Joined: Oct 21, 2008
    Posts: 33
    Hi Tim,

    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.

    Cheers, and cheers to JR for existing!

    Chris
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Managing changes in SVN/Subclipse
     
    Similar Threads
    is just Subclipse enough? or need install a svn server also?
    SVN: release branching, merging into trunk
    Questions about SVN and Intellij IDEA 8
    svn list command does not work
    Maven & Subversion