My current employer uses clearcase (I believe Base-CC) for version control. Our project has a branch, and each user has his own branch on top of it. The configspec of the users shows elements from the user branch, then from the project branch, and then from the company-wide branch.
The current modus-operandi, is that the users merge in their changes back to the project branch, and keep working on their own branch.
The problem is, that after the user merges his changes, he still has a branch for this element. Then, when the someone else modifies the project, he still sees his outdated version.
I want the following:
if a user has a checkedout file, display it.
if a user has unmerged worked, display it.
if a user has merged work, show the lastest version from the project
I thought of marking the element branch as obsolete after each merge, but the users still sees it, and not the latest from the project.
Then I thought of changing the config spec, to somehow ignore merged-in branches, but I do not know how to do that.
Any ideas?
You can reuse your personal dev branch, but the correct workflow, when a dev merges his/her branch to the upstream branch (here the project one) is:
first merge the project branch to the personal dev branch
resolve any conflict locally
then merge personal dev to project.
That way:
you don't have to modify the config spec after each merge,
you make sure the merge will be a trivial one,
and the personal dev branch can represent easily the LATEST from the upstream branch after merging (again) the project branch to the personal dev branch: the delta will be minimal.
Related
Setting up new projects and branch designs in TFS 2015. This detail may be significant - I'm using it for PowerBuilder projects, not .NET - VS2015 is used to set up branches and perform merges, the files themselves will be checked in and out in PowerBuilder. Far as I can see that shouldn't make a difference, but mentioning it in case I've missed something
Using the following sample layout:
Prod branches to/from Mod, down to Dev. New CO projects branch from Prod (so they always start with a fresh set of the latest live code), then merged (via baseless merge) to the DEV branch, and re-parented once the connection is set up. That way the users wouldn't have to remember to do a baseless merge; Dev will become the default merge target
Merges would them go back up from Dev to Mod, then back to Prod
The issue is that as a test, I tried the baseless merge after the branch, expecting no files to be merged, as nothing has changed yet in any branch. But the merge from the CO branch to Dev merged ALL files. Not an issue now since there's no changes in place, but would be quite a problem once several projects have been merged to DEV.
After that merge, I made a small change in the project and tried a merge; only the one changed file merged.
My best guess is that since the new CO branch was created after the Dev Branch, it was seen as everything in it is newer than the Dev branch, so it rolled over everything. Not sure how it would treat changes in Dev not seen in the Prod branch yet, haven't tested that scenario. It SHOULD at the very least tell me there's changes that I need to merge, but I fear it might just roll over them with the "new" files in the CO branch.
The question is, how can/do I tell the system that this new branch is "not newer" than the Dev branch? Does indeed the fact that these are PowerBuilder files somehow limit the ability of TFS of recognizing versioning in some way?
Or even more simply, is the branch layout I'm trying not the best method?
EDIT - here's the structure I'm currently using for my .NET projects - I was trying to use the layout above instead for the new code.
It uses the "Main" branch suggested below in the comments, but since I'm pulling "CO Branches" from Dev, I get code currently being tested, and not pristine Prod code. I'm assuming trying to branch and re-parent from Prod in this layout would result in the same scenario.
So is this the better way to go after all?
You may have a Main branch, which is the junction branch between development and release branches, representing a stable snapshot of the product.
You can branch from Main to Dev, Mod and Prod, when the work on Dev branch finished, merge from Dev to Main, when you want to release the product, merge from Main to Prod. So when you want to branch from the latest live code, you can branch from Main. In this way, you can merge from CO to Main, then Main to Dev or Main to Prod. All changesets will be reserved.
I am working on a project with some mates.
Yesterday I cloned the project with the intention to add a functionality.
I have 2 local branches that are develop (the main branch) and pageContent (my feature branch).
The problem I am currently encountering is when I edit something on my feature branch, it automatically edits it on my developp branch too (I did not commit anything).
I checked out on my developp branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
The branches seem to be auto-synchronised.
I checked out on my develop branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
This is how git works.
In the following diagram you can see the 3 states.
Git has three main states that your files can reside in.
They are all shared between your branches. but when you checkout branch you change the HEAD so you end up with the staging area && working directory shared between your repository even when you checkout branches.
Since you did not commit (i assume that what happened) when you switch branches you see the changes following you to your new branch.
If you don't want the changes to follow you you need to commit (or stash) your work before switching to the branch.
How to checkout different branch with clean working directory and stage area?
If you wish to checkout clean branch without any "leftovers" in your working directory and staging are you can create a new worktree which will result in shared view of your repository (all the content is shared) but with a different working directory and staging area.
From git v2.5
git worktree add <new_path>
Now do whatever you want in any of your branches. It will create 2 separate working folders separated from each other while pointing to the same repository.
Using wortree you don't have to do any clear or reset in order to remove all your staged and untracked content.
Here is demo of how to do it:
I don't know how to run command line stuff. I just don’t have the environment.
So I'm trying to rename a branch on the GitHub website. It was, by default, named patch-1.
Is it possible to rename it on the site?
I just did it without downloading any code to my laptop and using only the GitHub site.
The solution looks the same as #swcool’s, but I want to add about the default branch.
In my case, the name of the renaming branch did not exist.
Change the default branch (to the old branch you want to rename)
Create a new branch (with a new name)
This action will copy all the contents of the default branch (the branch with the old name) to the new branch (with a new name). At this time, you have two branches with the same code.
Change the default branch (to the new one with a new name)
Delete the old branch
I think you can, just create a new branch with the new name, and delete the old one on github.
More detail you can see here.
It is not possible to rename a branch from the Github website. You will need to do the following -
Setup your Git Environment
Follow this - https://help.github.com/articles/set-up-git
Rename branch locally & on Github
git branch -m old_branch new_branch # Rename branch locally
git push origin :old_branch # Delete the old branch
git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote
If you don't want to install Git, clone the repo, rename the branch locally and push it back to GitHub, you can use the GitHub API for references:
create a new branch where the old one is:
POST /repos/:owner/:repo/git/refs
{
"ref": "refs/heads/newBranchName",
"sha": "<SHA1 of old branch>"
}
delete the old branch:
DELETE /repos/:owner/:repo/git/refs/heads/oldBranchName
That way, you will have "renamed" (create+delete) the branch without having git locally.
And, as commented by user3533716 below, use the GitHub API for listing branches to get those branch SHA1:
GET /repos/:owner/:repo/branches
Since Jan., 19th 2021, you now can rename a branch directly on github.com:
Support for renaming an existing branch:
You can now rename any branch, including the default branch, from the web.
If you've been waiting to rename your default branch from master to main, we now recommend doing so using this feature.
When a branch is renamed:
Open pull requests and draft releases targeting the renamed branch will be retargeted automatically
Branch protection rules that explicitly reference the renamed branch will be updated
Note: admin permissions are required to rename the default branch, but write permissions are sufficient to rename other branches.
To help make the change as seamless as possible for users:
We'll show a notice to contributors, maintainers, and admins on the repository homepage with instructions for updating their local repository
Web requests to the old branch will be redirected
A "moved permanently" HTTP response will be returned to REST API calls
An informational message will be displayed to Git command line users that push to the old branch
This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch.
Branch names will not change unless the maintainer explicitly makes the change, however this new rename functionality should dramatically reduce the disruption to projects who do want to change branch names.
To learn more about the change we've made, see github/renaming.
To learn more, see Renaming a branch.
To rename a branch on the Github website, just go to your repo's home page, click on where it says "branches"
Then, find the branch you're interested in, click the pencil button
and from there, you can rename your branch.
If you want a GUI based solution - download the Git Client "GitKraken". It supports doing this from UI by right-clicking on the branch name and choosing "rename [branch name]".
Our dev team works inside existing projects, and deploys on completely separate environments. The work we do is not never expected to be merged back into theirs, but we are required to stay in line with them. They use the traditional trunk-branch (but not really tags) setup. A branch is created for a production release, and then development continues on it as they release.
The way our team does it, we copy their release branches to our own trunk (initially), which itself contains trunk/branches/tags. During development we are on trunk, and tagging for production releases. When we update from their latest release, its often impossible to do a straight merge from that branch to our trunk. It seems much cleaner and trouble-free to start with their branch, merge in our work, and eventually rename it to trunk.
All of a sudden I feel like a subversion dummy text generator...
Given the constraint that we can't change the other team's workflow, is there a better flow for us? Let me know if I'm missing something in the explanation too.
thanks.
Two main principles:
Vendor branches
Merge often
Due to ignorance of rule 2 you get "Merge hell" as expected
For more reasonable workflow (read about Vendor branches in Net, it has a lot of information) you can
Not just copy upstream branch to your trunk, but create vendor-branch (branch) in your repo, link it with svn:externals to source branch (without fixing source-revision in URL, link to moveable HEAD)
Copy branch to (empty) trunk
Monitor commits into upstream repo (SVNMonitor, CommitMonitor) and on every commit to upstream branch merge your vendor-branch with your trunk (svn 1.6-1.7 will be better than older versions)
After finishing upstream brach and starting new you can or edit externals definition in old branch (for next branch URL) or delete branch completely and start new (deleting all from your trunk not needed, only merge from new branch content)
I have an SVN branch and a trunk. The trunk changes regularly and the branch doesn't.
Every now and then (let's say once per week) I want to update the local working copy of the branch with the latest changes of the trunk.
Ideally I would want to do this the same way as I do it with the latest version of the branch: with Eclipse : Team->Synchronize, so I can review all changes before updating.
Is this also possible with a different repository (for example : trunk) ?
If not, how do people review the changes before updating then??
I looked at Team->Merge, but this seems to update the changes directly to my working copy, without the possibility to review the changes first (the Preview-function is confusing, I think, and doesn't provide the nice side-by-side view of changes/conflicts that Synchronize has).
The right way to do this is with Merge. Subclipse includes a merge client that makes this easy to do. You are right that it does not give you a true preview, but the way it works is better from a Subversion perspective. The Merge Results view UI is basically the same as the Synchronize view. It lets you easily examine every change that the merge made in your working copy and the Eclipse compare editor that it opens makes it very easy to take out any parts of the change that you do not want in your code before you commit.
The problem with trying to do this from the Synchronize view is that you are then doing the merge yourself using code editors and Subversion has no awareness of what is merged. If you let Subversion first do the merge, then it can update all of its metadata properly and it is perfectly fine for you to then fixup the code to be the way you want it before you commit the results of the merge.
I'd checkout both branch and trunk as a separate eclipse projects into workspace. Then use some merging tool, for example meld to merge changes between them. After merge you can refresh branch in Eclipse and synchronize it with svn repository - now you can review all changes. (it's how I do it, since I do not believe svn eclipse plugin ;))
I agree that it is not really intuitive by design, but Mark is right, you "synchronize" your changes when committing them back to the trunk:
first make sure your local branch is completely synchronized with your repository branch (no changes)
Team -> Merge... your local copy of the branch with the repository trunk
you now have a local version of that merge
you can locally edit this version, make sure tests are working and there are no compiler errors
finally you synchronize your local merged branch version with the repository branch and commit all changes that have been made
besides, the same way you'll merge your branch back into the repository trunk
make sure all changes of your branch are committed to the repository branch
switch to the trunk Team -> Switch...
merge your trunk with your branch Team -> Merge... (Tab 'Reintegrate')
you now have a local version of the merge, you may edit the changes and review them, make sure that you have a working version now
synchronize your local trunk (merged version) with the repository trunk
commit all changes that you want to appear in the trunk
i recommend to commit all changes that you've made locally to your merge, since you've tested them locally. if you commit just a few changes, make sure the repository version is still working then with missing changes