I am working with an SVN repository in Eclipse with the Force.com IDE. I am having trouble working with branches. Can anyone guide me on how to work with branches? I have gone through many blogs, but I didn't get any solutions.
asked Sep 5, 2013 at 14:41
Add a comment
|
2 Answers
If you are going to use SVN with Eclipse, my experience has always been that Subclipse works best. While using Subclipse, you can easily create branches/tags. They have some documentation available. Here is another article about Subclipse with some tips and tricks.
Subversion has a free book available that will detail out in more detail all of its features. For Subversion 1.7, there is an excellent explanation of branching in SVN. From the book:
What's a Branch?
Suppose it's your job to maintain a document for a division in your company—a handbook of some sort. One day a different division asks you for the same handbook, but with a few parts “tweaked” for them, since they do things slightly differently.
What do you do in this situation? You do the obvious: make a second copy of your document and begin maintaining the two copies separately. As each department asks you to make small changes, you incorporate them into one copy or the other.
You often want to make the same change to both copies. For example, if you discover a typo in the first copy, it's very likely that the same typo exists in the second copy. The two documents are almost the same, after all; they differ only in small, specific ways.
This is the basic concept of a branch—namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history (see Figure below).
An important concept to understand when it comes to working with SVN is the idea of cheap copies. This idea is utilized when creating branches. Also, from the book:
Cheap Copies
Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects.
This is why you'll often hear Subversion users talk about “cheap copies.” It doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's web site and read about the “bubble up” method in Subversion's design documents.)
Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and in space. If you create a branch entirely within the repository (by running svn copy URL1 URL2), it's a quick, constant-time operation. Make branches as often as you want.
answered Sep 5, 2013 at 14:54
I don't think there is a short answer to this. Salesforce makes it difficult. It takes a solid understanding of the theory of branching, discipline with branching every sandbox refresh, and a huge amount of patience with the limitations on how inconsistently metadata can be deployed from one sandbox to the next. Without an in-depth understanding of how the metadata you deploy does not necessarily equal what you would then get from a refresh, you will have no hope of getting an expected result from a merge. With almost any other platform (i.e. based around having code in a normally accessible filesystem), read and write are symmetrical but that is not always the case with the SF metadata API deploy and retrieve commands (the good news is that it works for classes, triggers, pages and components). Merge is not guaranteed to produce usable code, in any language I know of, but in salesforce, that is piled on top of those foundational challenges.
For an example, forget about branching for a second, and just try to go backwards a little ways. Suppose you want to test a snapshot of code from a month ago to re-examine how it behaves. You could do a checkout from version control, and your working directory (eclipse, probably) would get that metadata locally, but as you/it tries to re-deploy it to your sandbox, there's basically no telling what, if any of it, would have actually stuck, nor what the whole sandbox would look like. You'd then do a refresh from sandbox to see what you got, and it would be a new and unique mess of code & metadata from the revision you checked out and whatever on the sandbox until then. You could manually go into the setup on the web browser and keep making changes until refreshing metadata and diffing shows you no changes relative to your old revision anymore. Sounds fun, right? To do a merge (instead of the rollback example), you'd have to start in offline mode, resolve conflicts, and commit the merge before allowing eclipse to attempt to deploy the metadata, or you wouldn't have a new baseline to compare against. You'd have a mix of newly merged code and deploy+retrieve gibberish, and it would be ridiculously complicated to sort through.
This is why every other salesforce developer I know doesn't bother trying; they just do-over everything and copy whole files at a time or manually pick and choose diffs to copy between development sandbox and staging sandbox (then staging to prod should not be very confusing). They just do the best they can, all personally managing the whole process, and it works out ok for them.
So anyway, here is my actual answer: 1) practice branching and merging with something that has nothing to do with salesforce or eclipse, until you understand what it's supposed to do. 2) Do a bunch of practice merges on a disposable sandbox. Study the unexpected results, consulting the metadata & metadata API documentation where necessary. 3) get used to the idea that it will only go just so far in helping you.
Option 2: Forget about merging and get used to thinking of subversion like yet another junk drawer and only check out anything from it with an expectation that you'll have to personally vet every change anew (honestly it's not like merge totally absolves you of that duty, anyway); As long as you can generally find code you're looking for, you may as well copy & paste the bits you want.
Since you can get reasonably dependable results with classes, triggers, pages and components, you may choose a mix between the two, but you still have to find a way to deal with the reality of changing metadata that is not in those four categories - If you don't have the branch's objects, etc., is the branch's code going to be of any use?
