I need to create a branch for SVN project in xcode. I need to know what is trunk, tags and branches under xcode working copies configure.
How do i create a branch in Xcode editor? or i need to do only in terminal?
Below is basic understanding for terms you required.
Trunk: The trunk is a directory where all the main development happens and is usually checked out by developers to work on the project.
Tags : The tags directory is used to store named snapshots of the project. Tag operation allows to give descriptive and memorable names to specific version in the repository.
For example, LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT is more memorable than
Repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 and
Revision: 13
Branches: Branch operation is used to create another line of development. It is useful when you want your development process to fork off into two different directions. For example, when you release version 5.0, you might want to create a branch so that development of 6.0 features can be kept separate from 5.0 bug-fixes.
You could go through this tutorial for all basic concept and branching stuff.
Reference Link :
1. SVN tutorial
2. Create new branch in SVN
/----- UPDATE ------/
Below is screenshot for creating new branch via XCode.
Related
I have an ios standalone project managed with git in a git repository.
With this code, I am creating an ios dynamic library which will have some slight modifications from the standalone code to make it work as a library.
Now I have to manage two different code bases and whenever I make a change in the standalone project, sometimes I miss the changes in the dynamic library.
Is it possible to manage the common code in the standalone project and dynamic library from a common repository or what is the right way to do this?
I need to maintain standalone project separately because I cannot run and debug the framework easily as the standalone project.
If the standalone project can live in a subfolder of the dynamic library project, then you can use git submodule to reference a SHA1 of the first project into the second one.
git submodule add git#github.com:AFNetworking/AFNetworking.git Vendor/AFNetworking
Each time you modify anything in that subfolder, you can commit and push as usual, but also go back to your main project (the dynamic one), add, commit and push to record the new SHA1 of your submodule.
The other approach would be to use a subtree (as illustrated here, see tutorial).
git subtree add --prefix=Vendor/AFNetworking --squash git#github.com:AFNetworking/AFNetworking.git master
I prefer the first approach, but you can see both used in the context of a IOS project in this article
I'm currently using Team Foundation Server 2015 (Update 2) and wanting to use the new build definitions and release management and wondering what the best practice is around creating build definitions when using multiple branches.
We have multiple branches and there will also be multiple solutions in each branch (for this example i'll call them WinApp.sln, WebApp.sln & MobileApp.sln).
Our project branches are something like the following...
Project
Dev
Main *** This is our development branch for new features
Updates
1.2 *** This branch is used for any bug fixes for version 1.2
Main
Releases
1.1
1.2 *** Current release branch that will be deployed to customers
Using the new build definitions in TFS 2015 is it best to create a new build definition for each of the branches or each of the applications in each branch.
For example I create the following build definitions:
AppName.Dev.WinApp
AppName.Dev.WebApp
AppName.Dev.MobileApp
AppName.Updates.1.2.WinApp
AppName.Updates.1.2.WebApp
AppName.Updates.1.2.MobileApp
AppName.Release.1.2.WinApp
AppName.Release.1.2.WebApp
AppName.Release.1.2.MobileApp
And then that would flow through to the release management by having release definitions like the following:
AppName.Dev
AppName.Updates.1.2
AppName.Release.1.2
Each release definition will have artifacts added for each of the 3 solution builds.
Or would it be better to just have 1 build definition for each branch?
Would be interesting to know what other people are doing in similar situations.
Previously with the xaml based builds, we had multiple build deifnitions because whenever we released a new build template, we did not want the older release build definitions impacted, hence we maintained multiple build definitions. We also maintained that for the sake of the version the build gets.
But, with the new vNext builds in place there is no way we can have a previous version of a task available to use once we enhance a task and upload it to the TFS all build definitions start using the latest task and there is no way(other than renaming a task) by which we can select a task of older version. So, I think it would be of no use to maintain multiple build definitions, as the build definitions are going to get updated if a task is updated.
There is a case where we require to maintain a version for a specific release and if the number depends on the builds triggered, in that case we'll have maitain different build definitions becuase our patches cannot have the latest version number.
One more reason to maintain different build definition is to escape from the headache of remembering what tasks were used in a specific release previously.
So all in all I'll go with different build definitions to avoid versioning chaos and to maitain integrity of a release build definition.
When it comes to release,we bind a build definition to a release definition. So, again to have a smooth bug fix and update, different release definition for each build definition has to be present.
We're updating a large project from VSS to TFS2010, and we need to establish good branching/merging strategies. We are in favour of feature-branches but I have no idea if we should branch only the sub-projects/files affected in each feature (like we would in VSS) or should always branch the whole code-base and rely on lazy copying and good merging (like in git/mercurial).
The guides I've found so far online talk about branching strategies (branch by release, feature, etc) but not about which files/sub-projects you should perform the branch on.
Is there a "right way" to do it? Say we have a setup like this:
Code
|
|- ModuleA
|- ModuleB
|- ModuleC
|- ModuleD
And we have a feature F which impacts ModuleA and ModuleD. Would we be better to branch Code, or ModuleA and ModuleD only?
If your feature is impacting something that is used throughout your codebase, branch your entire codebase. You still want to have CI builds running on your feature branch, and thus you want all of your automated tests to run, same as always.
Even if a feature only affects one small segment of your application, you still want to be able to test the application as a whole to make sure you haven't introduced any breaking changes.
I recommend reading the ALM Rangers' branching/merging guide, which you can download from CodePlex.
I read lot on this subject (Techdays, videos, etc.), on my project apply this strategy, it's recommended as best practise.
The implementation requires performing the following tasks:
1 . Create a truncated development , trunk reads XYZ
Note: developments are not directly on the trunk, but are about a girl called Service Pack branch .
2 . Create from the trunk a new child branch service pack, language 1.YZ
Note: This branch will host the first dedicated development functionality.
Event Project: End of first iteration ( The development team believes that the developments are completed).
3 . Create from Service Pack 1.YZ a new child branch Fix denominated 1.0.Z.
Note: This branch contains all developments dedicated to future bug fixes following the delivery of the target feature.
4 . Create from Fix 1.0.Z. a new child branch Release denominated 1.0.0 .
Note:
This branch will remain read-only.
This branch is the only branch deployed in a production environment .
This branch is a picture of our delivery.
It allows you to draw different deliveries made .
It allows to perform operations on the Rollback version if the need arises ( Avoid conflicts file version ) .
Event Project : Delivery of production
Deliver Release 1.0.0 branch on the production environment .
6 . Merge Service Pack 1.Y.Z to X.Y.Z trunk
Note : At this point all branches are at the same level of evolution .
Event Project: bug occurs on the Release 1.0.0
7 . The treatment of bugs can be done in two ways as possible :
■ If it is determined that the version is not stable
Carry - on patches Fix branch 1.0.Z.
Create a new branch Release 1.0.1
Deliver the branch Release 1.0.1
Merge Fix 1.0.Z to Service Pack 1.Y.Z.
Merge Service Pack 1.Y.Z. to trunk X.Y.Z.
Note: You can iterate many times : 1.0,1 , 1.0.2 , 1.0.3 etc. .
■ If it is determined that the version is stable and we decided to fix bugs on a new delivery.
- Create from Service Pack 1.Y.Z. Fix a new child branch 1.1.Z
Make corrections on Fix branch 1.1.Z
Create from Fix 1.1.Z. a new child branch Release denominated 1.1.0 .
Deliver the 1.1.0 branch
Event Project: An important new feature comes
8 . Create from the trunk a new child branch service pack, language 2.YZ
Reproduce the same organization ...
Remark : on my blog i writted post
In xcode 4 organizer there was a button "import", in xcode5 how do I import a project in my svn repository?
thanks
The question is a bit confusing so please advise if it's not exactly what you need (otherwise, feel free to accept the answer). The confusion is that the Xcode 4 workflow you describe is used to allow developers to manage repositories (svn or git). If you want to take an Xcode project and add it to an existing svn repository I am attaching links to answers for that question.
Adding Xcode Projects to SVN:
Stack overflow response
SVNBook
High-level Concepts (Xcode 4 Workflow in Xcode 5):
Tell Xcode 5 about a repository (it will auto detect the type of svn
or git)
Check-out the repository for insertion into a different project
Background:
In Xcode 4.6.3 there was a repository area of the organizer. This is where subversion and git projects were managed.
New Workflow:
The new location for this information in Xcode 5 is in Xcode > Preferences > Accounts > Repositories (menu on the left) > (+) Add Repository... (on the lower left)
Once selected one may enter a repository address (local or external):
And give the repository a directory name (credentials for many public read only repos are optional):
With Xcode 5, one can then download the repository to a target folder by going to menu Source Control > Check Out...
As part of the checkout wizard one will be authenticated to the repository:
Select a target folder to store the local repo:
Edit basic repo properties:
For more information on adding projects to repositories:
Xcode 5 Source Control Management Documentation
As far as I can see, you need to know the exact path to be able to check out a project. This seems like a step backwards.
Been using TFS2010 for just a few months now so relative newbie, and now possibly need to create my first branch, unfortunately I need to create it from an older changeset, is this possible?
Basic scenario is I converted a project from VSS 6.0, with history, and it all came over fine. Project has approx 500 source files.
Before the conversion from VSS we started working on version 4.0 of our project, with no plans to release any more bug fixes to 3.1 so we didn't establish any branches at that time.
So we have made significant changes to about 20 files (which I can identify), but now the client wants to release a 3.11, 3.2, 3.3 etc because not everyone will be ready to go to 4.0 product anytime soon.
I think we want to create a branch, and then use TFS to rollback about 20 files in that branch to an older version, is this possible to do? Create a branch from where we are now, and then rollback some of the files? or does creating a branch cause you to lose history for that branch?
Slightly complicating things is that after we started working on 4.0, besides making the 4.0 specific changes we also have several changes that we made that would need to go into both he 3.1 branch AND stay in the 4.0 branch we are working on now, and furthermore, and more bug fixes we need to put in over the next several months would need to apply to both branches.
Perhaps this is a pretty straight-forward use case for TFS, but just wanted to make sure I don't mess up what is already working perfectly fine.
Suggestions?
You can create a branch from any changeset, and it's very easy from within the Source Control Explorer UI. Just navigate with Source Control Explorer to the server path you want to branch, select branch, and then you'll be given the option to "Branch From Version". Just select whatever changeset you want to branch from and your new branch will be created from that instead of the default of the latest version.
Why don't you choose to get the appropriate base version with "Get Specific Version" which will summon the sources in the state you need - of your version 3.1.
Then construct a branch to continue work towards 3.1x
Executing 'Get Latest' on your base branch should result with your sources in version 4.0
I have just done this.
I started my solution with a single branch team project in codeplex :
-MyPrettyCMS/Database
-MyPrettyCMS/Framework
-MyPrettyCMS/Layers
-MyPrettyCMS/Portals
-MyPrettyCMS/Solution
It's not possible to create a branch of the team project
WARNING ! I tryed to convert Team Project folder to a Branch, it worked but after that, I can't create any branch and I had not enough rights to undo that (I had to ask the Code Plex TFS Administrator to undo for me).
All of this must be done with team explorer and not with solution explorer.
So I created a Team project folder subfolder CurrentRelease like this
-MyPrettyCMS/Database
-MyPrettyCMS/Framework
-MyPrettyCMS/Layers
-MyPrettyCMS/Portals
-MyPrettyCMS/Solution
-MyPrettyCMS/CurrentRelease
Then, for each folder I used the team explorer move command (DON'T MOVE FOLDERS with the Windows explorer even if you have the plug in, because sometimes it fails).
The result is
-MyPrettyCMS/CurrentRelease/Database
-MyPrettyCMS/CurrentRelease/Framework
-MyPrettyCMS/CurrentRelease/Layers
-MyPrettyCMS/CurrentRelease/Portals
-MyPrettyCMS/CurrentRelease/Solution
At this point you must archive each CurrentRelease subfolder
Now you open windows explorer and you verify each folder and its descendent to see if you forgot some files. If you did, copy it to the new folder, add it to archive with the Add files of Team Explorer. You must archive again.
Right click on MyPrettyCMS/CurrentRelease ans select command create a branch
I used CurrentRelease-To-2-50-001 as Branch name
Then I have
-MyPrettyCMS/CurrentRelease/Database
-MyPrettyCMS/CurrentRelease/Framework
-MyPrettyCMS/CurrentRelease/Layers
-MyPrettyCMS/CurrentRelease/Portals
-MyPrettyCMS/CurrentRelease/Solution
and
-MyPrettyCMS/CurrentRelease-To-2-50-001/Database
-MyPrettyCMS/CurrentRelease-To-2-50-001/Framework
-MyPrettyCMS/CurrentRelease-To-2-50-001/Layers
-MyPrettyCMS/CurrentRelease-To-2-50-001/Portals
-MyPrettyCMS/CurrentRelease-To-2-50-001/Solution
I archived the Initial version of the branch.
Now I can work on my next release and make some minor corrections to the current release.