We have a recent requirement at my workplace wherein we have a baseline Android project (trunk). Other projects will need to (svn) branch out from this baseline Android project and start their own line of development.
Now let's say that the current state of my svn is:
--r19--------r30----->my.package.baseline(trunk)
|
|--r24--r29------>my.newpackage.projectA(branch)
r19: created the projectA branch
r24: renamed my branch package
r29: made huge updates
r30: bug fixes and upgrades to baseline project
If I want to apply r30 to all my other branches, would it work fine if I do svn merge even if the directory/package has already changed due to r24?
If what you are asking is just would you able to commit, the answer is yes.
If you are lucky enough that files been changed in r24 and r29 are just different files with what's changed in r30, then it would just work without any problem.
If some files got changed in r24 or r29 has also been touched in r30 then you might run into a svn conflict, it will work still as long as the person perform the merge understand code changes in both branches(trunk and your branch), this person not just need to solving obvious svn conflict(same area in one file been changed in both branches), but also need to solve the code logic conflict, that I mean things like no svn conflict but it won't compile anymore, or the logic conflict between changes introducing new bugs in your code.
My suggestion here though, after the merge, commit immediately after solving svn conflict, don't worry about any logic conflict. You solve the logic conflict in a separate new commit. This will save your some rare trouble when you merge back into trunk from my experience. As what the svn does with the merge, it modify the mergeinfo attribute, for your example mergeinfo in your branch would be something like
trunk: r30
svn would be using this information to figure out how should it perform a merge when you decide to merge back into trunk, if your branch has everything from trunk to date, it simply replace trunk with your branch assuming your solved all conflict, if you do cherry-pick however, it use thing merge info differently to try to solve conflict automatically if possible, so if you commit logic fix in a different commit it would less likely run into svn conflict.
The longer a feature branch runs the more problem you would be facing if trunk keeps changing in the meantime. But it is what it is, that's how branching works, you should have a plan about how often you are going to merge from trunk and how long you want to keep your branch. Try to slice your task to smaller pieces so your branch has a shorter life span, for example two weeks, it would make a big difference comparing you keep a branch for three month and then merge back all those changes into trunk.
Related
Let's say I forgot to commit at the moment of compiling my APK.
I continued modifying my files, and then committed later on.
Can I go back to the precise moment of APK compilation, which is unfortunately between two commits?
No, you can't do it - some things you can do is either go back to your old commits and start again(not recommended)or:
If the change was not so large you can see what exactly did you changed and start hard copy-pasting and return to your old version of the code.
But the best thing I can recommend is to use branches - start a production branch(only stable code goes there) and dev branch(in this branch you can modify your code as you want because you have another stable working branch)
Edit: as Zoe mentioned in one of the comments - check for local history in your IDE (the link gives example for android studio IDE)
I am new to Git and do not understand everything yet. I usually commit after each app update and then create a new branch for the next app version, so that I can correct bugs of the currently published version while working on improving the app for future versions.
So far it was just a precaution and I never really used it that way but I want to get serious about Git capabilities. And I face this problem:
I have two branches in addition to the master, and if I compare the files from the two branches, I can clearly see the differences.
However, if I "checkout" from one branch to the other, nothing happens and it seems that the current code is just reassigned to a different branch.
But what I want to do is to be able to modify both codes in parallel.
How does it work?
Thanks.
First you have to do the changes in one branch. Then you can share the same change to other branch using git. There are multiple ways to share the changes, based on the different scenario.
They are "Cherry pick", "patch", "merge" and "stash"(additionally shelve in android-studio).
Based on the scenario shared above, you can use patch to share the code among branches.
Make changes in one branch and commit it.
Right click the commit in android-studio and select "create patch".
Checkout to another branch.
Select options VCS ---> Apply Patch.
Select the "patch" file and apply it.
Now you can able to see the changes you made in the "other branch" in "current branch".
Then you can commit the changes in the regular way.
I have two branches, the development and the master.
Code in master branch can't have Log calls, comments, etc . Everything else is the same.
So when I merged to the master before commit I deleted everything I didn't want.
I continued developing on development branch and now I want to merge and commit the changes but I guess that will add again what I have previous deleted.
Is there a way to commit only the changes from the development branch or a workflow/solution for this problem ?
I'm using mercurial but I guess someone who is facing the same problem with git can help.
I'm new with mercurial and don't know much about git.
Thank you
Ideally you need to find a different method for tracking/sharing such items but if that is impossible then you could possibly use python hooks to filter them out of any commits to your master branch.
See this chapter of the hgbook for some discussion of some of the possibilities.
So I have managed to get a couple apps up on the marketplace only to have a stray thought of what is the best way to go about managing my projects/apps within eclipse to accommodate future updates to the marketplace. My question resides within Eclipse and what to do with my projects/apps as I apply updates.
Do I simply copy my project/app, paste it and the increment the version information accordingly? Or am I continuously working on my published project/app? Or...Is there a recommended/preferred method of going about this. Since they are up and good on the marketplace I am leery of doing something that will cause problems for me later on down the line.
And don't change the package name....correct?
This is what I currently have on the Marketplace...
Wind Chill Calculator
True Love Game
First of all, everyone's posts were very helpful and I have spent some time looking over documentation through the links provided.
So...and brace for impact as I say this. Being one who has NEVER used any form of SCM for my projects this is all new to me (as everyone's faces cringe), which is why I am asking the original question in the first place. I hate to say tell me anything without doing my research...so within the past few hours using git within eclipse I have gleamed the following:
Team > Share Project ...ignores...any tags(for version info)which is what I am after...commits...THEN
Clone? File -> Import -> Git -> Git Repository at this point once I have cloned my project do I create a new tag with the new version info, and go through the commit process again? If this is the case I now have two items in my Git Repository. One of which has the single tag of 1.0, and the other item which contains two tags 1.0 and 1.1, and when I look at the history I see two tags Version 1.0 and Version 1.1. Then I just switch between the resources I need from within the repository?
I just want to make sure my process is correct before I begin to implement some of this on existing projects that are pretty extensive already. As for the rest I am just going to learn on the fly...branches
You might want to use a revision control system like SVN or git or one of dozens of other options, and continuously update the single project in Eclipse. The benefit of using source control is that you can branch into a new project for major changes, update your existing code for minor changes, and tag the branches so you can revert back to an old snapshot in the future.
I personally use bitbucket which is hosted remotely and is free. It supports SVN and Mercurial.
No, dont change the package name, that will make it new app, instead of upgrade of original.
Use a version control system, like SVN.
Manage Tags for a complete working state of code(through svn), so you can always revert back to that tag.
When ready for new release, increment version no. etc and update on market...
EDIT After addition in question:
Don't get much confused with various GIT/SVN working.. There main purpose is that they will allow you to switch your code back and forth to any point in past, that allows you to code in a way properly knowing that you can always revert back to a Working state.. and it is definitely of much more benefit in a Team , when multiple people are working on same codebase and possibly same files...
Being a long-time user of SVN, I recommend subclipse (svn for eclipse). When you're ready to release another version of your app, create a 'tag' for the release version and you'll always be able to go back to that exact version.
SVN has excellent docs. There is also TortoiseSVN for repo work outside of eclipse.
I have a very basic question about SVN. I know SVN has pretty strict rules about things & was wonedring if I would mess up my project if I tried this.
I use two computers regularly - onsite & from home. I have Eclipse(Galelio) + subclipse(1.6.x) installed on both. If I were to checkout the same project from SVN repository on different machines using the SAME user ID, would there be any sort of problems during commits or updates?
I will be committing from different machines regularly, but of course it will be the same user ID.
In SVN, each commit is identified, no matter of the user that made the commit.
User that made the commit is only an information like the commit message, nothing more.
So, you will be able to commit on your 2 working repositories without less or more conflicts than if the commits were done by different users ;)
SVN does not track checkouts, it does not matter what username you use. You could even zip up a checkout on one machine move it to another and unzip it.
At commit time, the username you provide will determine the author for the commit. On your other machine, which does not have this commit, an svn up will bring in this new commit fine.
In short, the author name is just a piece of information for history log. It is not going to cause any problems to use the same repos from different machines.