What I would like to achieve is that no longer used (feature) branches in gerrit are blocked for the submission of new changes and patches.
The gerrit documentation just says how to do it, but not what the effect is (or I did not see it).
I could try to find out by running a few experiments, but that will not necessarily give me the full picture. Can someone point me to more documentation or tell me from experience and/or insight into the codebase?
Possible effects could be:
No more pushes to refs/for/deletedBranch allowed (certainly)
Branch removed from underlying git repo (I guess not)
Not yet merged changes posted to refs/for/deletedBranch disappear (hopefully not, there should be a guard against this case)
Already submitted/merged changes and their patchsets disappear from the listing of merged changes (hopefully not)
What will really happen?
Related
Do you really need a Branch to CheckIn / CheckOut Code in TFS i.e, just add files to a folder ?
What would be advantage to Branch in that case ?
You do not need a branch to check in and check out.
Branches however provide you with the ability to make changes to more thank one version of your code at once. Lets say that you have one folder at $/ProjectA/MyAwesomeApplication/Master. You can happily work away, checking in and releasing. At some point you find a bug in production that needs fixed immediately. However MASTER is well beyond what was last released and you don't want to deploy those changes yet.
You know which build is deployed and thus which changeset. You can branch MASTER at that changeset (the past) and create $/ProjectA/MyApplication/QuickFix. There you can fix that bug and ship, then merge back into MASTER and delete that branch.
Now obviously this is expensive and time consuming. A better way would to move forward and just ship what is in MASTER. If you have feature flags and good testing them you should be able to do that. There are however always those exceptions to that rule, and that's where branching comes in.
If you are using Git in TFS rather than TFVC the story is different.
It seems that Plastic SCM does not track code moved between files (compare with e.g. Git) Am I right, or is there a way how to switch this feature on?
(Disclaimer: I work for Plastic SCM).
As far as I know git is able to track moved fragments of code between files when you run a "git blame", but it doesn't use this information during merge, correct? Git is able to calculate the "moved fragment" between files if it happens on the same commit and that's what it does while processing the 'blame'.
No, Plastic is not able to do that yet, which is a shame because we're already doing some interesting things around the idea:
First we have semantic method history which is able to track the history of a given method even when it has been moved, renamed and modified, but always inside the same file. We have plans to extend this to a repository wide basis, indeed we were about to implement it by the end of last year but we had to postpone it since we got some other highly requested features to work on.
The 'semantic method history' is based on the SemanticMerge tech we've developed. Right now it also works inside the file, but plans are also to come up with SemanticMerge multi-file (we even have a working prototype already). I expect this to be several steps ahead of what other tools can do.
Applying the last two together it wouldn't be hard to do something like 'blame with moved code', which as you pointed is something really great to have. Hopefully we'll release something like this in the coming months.
I can't figure out the best way to do this and it has happened a few times where I mess myself up that it'd be nice to know a possible good way for this. On master, I have our main project. We finally got approved to use ARC in iOS and I created a new branch for that to not mess with the main working master branch. I also took the time to delete some unneeded files in my ARCBranch. What I want to do is use this branch for development for the next release. I'd like to pull in the changes from master to the ARCBranch. So I switched to ARCBranch, and did
git pull origin master
I got conflicts, some which were straightforward because I could see the code, others being changes in the pbxproj file where I cannot tell what's what. I did see
<<< HEAD ==== >>>. I can't tell what I need to do here. I can't open it in Xcode, only a text editor. I tried just deleting those <<< === >>> characters since I saw one person on SO say that you typically want both changes and that you could always do that. This didn't work for me. I was wondering if there is a better way to do this change. Maybe somewhere where I can see each change by change happen? Thanks.
Instead, you could try
git rebase master
This would apply the changes commit by commit. If there are conflicts, it would stop there, so that you can resolve them and do
git rebase --continue
to finish applying all the patches.
It failed to auto merge so it marks the conflicting blocks of code and leaves them both so you can decide and remove one yourself.
I'm finding that a number of my changes are being 'lost' when our contractor performs a check-in.
The general process is as follows:
I perform some bug analysis and implement a fix.
I then check-in my code.
The contractor performs a check-out/check-in at a later date.
The changes from the previous changeset (my changes) are lost.
In my view, this is pretty unacceptable, particularly when I'm dealing with application-breaking regressions introduced since the last build.
This has happened at least twice now, and the only thing I can think of is that the contractor is failing to ensure that he has the latest changeset at check-out. Our repo does not allow multiple check-out, and forces get latest on checkout, which makes things so weird (seeing as we both should be working with Server workspaces).
Could there be any other cause of this problem? I don't want to take my concerns to my line manager without being sure I've covered all bases.
Get Latest item on check out is set in the client and not in the repo, which means that your contractor may still be able to checkout the wrong version. They should get merge conflicts upon doing so, but that depends on where they edit (and how they manage such conflicts).
I've seen TFS lose changes this way. I have yesterday gone to a client site, made changes, checked in, today come back to my office, got the changes (assuming it will merge with my local changes like it usually does), gone to check in just now and I can see in the diff that it's wiped out the client-site changes (obviously ignoring the merge locally). I checked in just to confirm what I was seeing and yes there was no resolve conflict needed, TFS thought everything was ok, but my modified local file just blatantly overwrote the modified version in TFS effectively discarding the whole client-site change (just like if I'd chosen resolve conflict keep mine - however it never asked me about the conflict or suggested that there was one, just silently lost it)
If you eye-ball the changes before committing you can see that the changes you are making are more than you thought - i.e. the client site changes are effectively being removed and will show as differences - however it's easy to miss this when you are doing it a lot.
I had previously thought to blame coworkers when they skip out my changes this way, but now I've actually seen myself do this to myself I realise the tool is deficient. Hard to believe but there is obviously something wrong with the way it merges your locally changed file against the 'get latest'. I'm using a cloud TFS with a flaky network connection sometimes - I'm told this contributes to the issue.
After merging a branch back to the "trunk" what do most people do with the branch. Just delete it? Move it to another area? Change it's permissions?
The concern we have is that developers who are away, and don't read their mail could come to work and continue working on the branch, after the merge has been done.
Once the branch is definitely dead then I like to delete them. You can always undelete something in TFS if necessary (Options, Source Control, Show Deleted Items). Dev's working in that area without realizing it may get some strange behaviour (i.e. files dissapearing when they do a Get Latest) however it get's them to figure out something has happened pretty quickly.
That said, sometimes it can take a while to ensure that the branch is definitely deceased in which case changing the permissions on the branch so that only a limited number of people can edit the files on that branch is a handy technique. You can have one person lock all the files in the branch with a check-out lock but I've not found that to work too well when freezing a branch - permissions seems to work better so that you do not have to have a bunch of pending changes (the locks) to manage for all the files in the branch and also you can have more than one person working on it while it is being frozen.
We delete branches, once we're sure the merge was successful.
We move them to an Archive folder. We should probbaly change permissions as well.