Jump to content

Error when switching to new branch


ShadowMage

Recommended Posts

I think I may have hosed my repository but I'm not sure. Hopefully somebody can help, because I'll be losing a fair bit of data if I have to restore my repo from backup. It's a really long story, but here's the gist of it: I wasn't happy with how I was handling the merging, tagging, and exporting of my live and development versions. In my repo, the trunk was basically my development version, which meant that when minor bugs occurred in my live version, I couldn't use the repo to make changes. It got messy fast. So I restructured the trunk to have two branches: live and development. Here's the problem. I have several branches (created from the original trunk) and now I've completed one of them (let's call it Comments) and need to merge it with my development branch of the trunk. When I tried to switch to the development trunk branch to reintegrate the Comments branch, I got this error: 'file:///C:/.../SkyPrice/trunk/Beta' shares no common ancestry with 'K:/.../SkyPrice_WIP' Is there another way to merge the two or am I stuck? As I said, if I have to restore my repo I'll lose a significant amount of data (though I could find a workaround) because I've made a lot of changes to the branches I have since change the repo structure. Help please? Thanks.

  • Like 2
Link to comment
Share on other sites

The whole point of tags is for them to reflect the different "live" versions, while the trunk is supposed to reflect the development version. Your first error has been trying to restructure the trunk.Create a new tag for the "live" live version, and restructure the trunk back to the old structure (for it to be development only).BTW, it sounds like you may be in need of switching to Git or another distributed VCS. With them, you can have multiple repositories that sync to each other on demand, so you could have a "live" repo syncing with a "dev" repo only when you're ready with something. You can copy and edit the "live" repo when there's a serious issue, and merge back with the "dev" one afterwards. In addition to that, Git's "submodule" feature (basically, the ability of making a shortcut to one repo to within another repo) could help with modularity.

Link to comment
Share on other sites

The whole point of tags is for them to reflect the different "live" versions, while the trunk is supposed to reflect the development version. Your first error has been trying to restructure the trunk.
I know. But you're not supposed to make changes to tags right? Occasionally, bugs appear that require immediate attention. I can't make these changes to the trunk (or a new branch created from it) because there could be other under-development changes that have been committed and merged with the trunk. How do you recommend I handle these changes?
Create a new tag for the "live" live version, and restructure the trunk back to the old structure (for it to be development only).
Is there a special way to do that? Or do I just copy my development files back into the root of trunk and delete the two branches?
Link to comment
Share on other sites

How do you recommend I handle these changes?
One way is to "tag" the latest tag into a new one, and then commit any changes over that new tag. With this approach, you must also remember to fix the trunk though (which you can do in a single commit if the fix is trivial enough).
Is there a special way to do that? Or do I just copy my development files back into the root of trunk and delete the two branches?
Depends on how do you originally restructured the trunk. If you just created two folders, moved stuff appropriately into them (without SVN commands), and committed, doing the same thing again should work.
Link to comment
Share on other sites

One way is to "tag" the latest tag into a new one, and then commit any changes over that new tag. With this approach, you must also remember to fix the trunk though.
I guess that would work. Not any more work than what I was doing. ^_^
Depends on how do you originally restructured the trunk. If you just created two folders, moved stuff appropriately into them (without SVN commands), and committed, doing the same thing again should work.
Are you talking about making these changes to the working copy and committing them to the repo? I actually did everything through the repo browser (in Tortoise) but reversing the process seems to have done the trick. Thanks for your guidance, boen. Very much appreciated!
Link to comment
Share on other sites

From what I have learned, the general workflow is something like this. trunk/master - this is the main line of development. This is essentially what you would give to the client. Although it may not have all the features and functionality needed for your next official x.x.x release, it should be the most stable environment that you would want to release/tag from. branches - these are offshoots from the trunk/master. Say you want to add a new widget to a page or pages. From the trunk, you would create a branch. You can do all your work in there. Depending on how long the work takes, you may want to regurarly merge the trunk into your branch to minimize conflicts when your new feature branch is ready to be merged back into the trunk. tags - these are a snapshot of your work (from the master/trunk) at specific times. Usually made when you have make a release (i.e. fancy-app-1.2.0). This is very helpful for creating changelogs, because then you can diff between the tags and see what's changed, and in what files. Tags should never change. Even if you find a bug, if it's quick, do it right in the master, and then release and tag (i.e. fancy-app-1.2.1). SVN and Git offer their own features and workflow paradigms, but the general principle behind these above terms is pretty much the same. Where as SVN is centralized, Git is distributed. But usually you always end up pushing back to an origin. With Git, you have the opportunity to commit/stash locally before pushing your changes, amongst other things. to manage live and development, I would still keep all your work in the trunk. Do things you need to do, with branches for features if you need (depending on if you have other developers or not). When it comes to update your application on production, I would create a tag (and change any config values you need) from the trunk and then push that tag to the production server. A build process like Maven would help you in this case, because then you could use filter properties during the build lifecycle to automatically plug in config values for you so you wouldn't have to do it manually.

Edited by thescientist
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...