I am resolving two issues simultaneously, but I want the reviewer to see my changes for each issue separately. I am thinking that if I create two pull requests (one for each issue), each issue will be easy to review.
My current guess is to create a separate branch for each issue, place my commits on each branch separately, then create a pull request for each branch. The reviewer can then see the changes pertaining to each issue, but will have to merge in each branch separately. None of my code for either issue will overlap, so merging each issue should not be a problem.
My other guess is to log which issue I am addressing in each of my commits and then create one pull request. The reviewer will have to parse my commits to see which issue I am addressing, but will only have to merge one branch. This is a simpler approach, but is it preferable?
Or is there an easier way to do this? Let me know if I can clarify anything.
Merging is easy.
Deciphering your intent is hard.
By keeping the work on the two issues separate you are allowing the reviewer to accept, reject, or ask for improvements on the issues independently.
If they were merged and you need to make a small change for one of them, both improvements are blocked until the change is made and reviewed.
Related
I am currently working on two different sub-project. Till now I have had two different mercurial repositories for each. I would like to keep the two sub_projects all in one repository, but then I still would like to be able to work on the two sub_projects simultaneously and separately without having to commit changes from both sub-projects all in one commit. My two sub-projects are totally independent.I would like to be able to commit and see the history of each of the sub-projects independently.
I was wondering what is the best practice in this case. I would like to keep the two sub-projects all in one repo as this will make delivery to the client much easier.
Thank you very much in Advance for your help,
If it's two unrelated code bases, then my recommendation is to NOT merge them into one - it won't make handling any easier.
However if you are set on creating a common code base, then there are different strategies:
a) Just merge them in one repository by pulling one project into the other. This requires that there are no identically-named files in the two repositories. Alternatively use the convert extension onto either to put them into separate paths, then pull the converted repositories into one. You will have to take care manually that you make commits such that you only touch files of one project at a time.
b) Make use of sub-projects. The best choice for separate sub-projects is to use the subrepository extension of mercurial; it's recommended to use a shallow parent repository of which the two sub-projects are just that: sub-repositories. Mind to read the documentation of the subrepositories extension carefully - it's called a 'feature of last resort' for reasons that it does have its rough edges. However you can commit to the single sub-projects separately without touching the other one and create a common state of the projects by making a commit in the parent repo which records the state of the sub-projects.
There are also similar alternative extensions like guest repo and similar - maybe they suit your use case better.
My question is similar to: Mercurial branches with different codebase
But the solution given there was to do all the work on the one customer branch and merge it to default. I don't see how that is workable in my case.
I have a project that gets distributed to 4 customers. I've setup a named branch for each customer. What is an effective way of merging changes to common code, while leaving alone some customer specific data and/or requirements?
Edit:
I have customers a,b,c. Machines M,N. and parts 1,2,3,4,5.
Right now I have subrepos a,b,c,M,N,1,2,3,4,5 and repos aM1,aM2,bM1,bN1,... . I am considering having subrepo customer (branches a,b,c). machine (branches M,N). parts (1,2,3,4,5)
Are there techniques for making change propagation easy, but also keeping some differences permanent. Maybe something like this:
TipsAndTricks.
Based on your question and clarifying comment, what you want is both impossible and not really what hg is supposed to do.
Everything I am about to say, I say as someone who has made exactly the kind of mistake you are about to make and who has lived to regret it (and slowly, painfully, try to undo it).
As I said in the comments, this seems like a faulty design. If you want something to be part of a code base only for some purposes, then that's a good indicator that what you really need is one of the following:
more configurability to turn features on or off,
a custom build script to assemble various versions of the project, or
a core code base and several customer- or purpose-specific code bases for plugins and add-ons.
You probably don't want customer-specific functionality---and definitely don't want customer-specific data---in your main project's source tree. Anytime you are about to commit a change that includes either customer configurations or code that only one customer will ever use, you need to step back and ask (1) why it should be in your core project instead of a plugin and (2) what the implications would be if another customer or third party ever got access to it by mistake.
I see at least two possible ways:
Customer-specific changes are always in separate changesets, and you move common changes from customer-specific branch into mainline not with merges, but using hg graft, cherry-picking only needed changesets
Using MQ extension, you can have customer-specific changes in MQ-patches (patch per customer), applied|unapplied individually on demand and just merge branches
In the last case separate named branches may be not needed at all (you have default and different patch applied for each customer) - at least I moved to this workflow, when I had to maintain a set of clones with only slightly different configurations and merging from default to each branch become boring
I've thought this through and I think I understand the implications, but I wanted to get a sanity check because the caveats on https://www.mercurial-scm.org/wiki/ShareExtension are pretty general.
Specifically, the warning is "It's probably not a good idea to mix MQ and shared clones; if you do so, you should definitely avoid pushing/popping patches in one clone while another clone has patches applied."
However based on my understanding of how Mq works, it's only unsafe to push/pop patches (create/destroy history) if you have two shares whose working directory parent would be affected by such changes. That is, if you have two shares that are updated to separate named branches, pushing/popping patches from one should only have the effect on the other of creating/destroying history that is unrelated to the working directory and thus should NOT have any undesirable side-effects.
There will be small side effects, such as revision sequence number changes in some situations, but nothing that should jeopardize correctness or cause problems with the working directory.
Is this correct or am I missing something?
I'm not sure about this, but AFAIK if you end up having the exact same file content in both branches (repos), this might still wind up as shared storage and wreak havoc.
This is obviously not a definitive answer, but I just wanted to report back in case anyone else is interested in this situation. I've been running for several months now with multiple shares on a "central copy" of a large repo, with each share being dedicated to its own branch, and using MQ freely within each share. I have not hit any problems. History changes on other branches just look the same as pulls/strips would -- unrelated changesets being added, modified, and removed.
I'm very new to SCM, and I'm aware that there are some guidlines and recomendations to follow , but I'm not aware of any of them. There are several things that keeps me confused about SCM. For example:
I know that it's a best practice to commit as soon as possible and as often as possible, but what should I do, if I'm working on a change/feature that requires several days or even weeks? I could split the task but, mercurial says that one should never commit change with future change in mind. Every change in commit should be in final stage.
In what situations are branches useful? except splitting different releases in SCM.
Why and when should I clone a repository?
Sorry for those dumb questions and my broken English, I read many articles about SCM on the net, but every of them contains conflicting information for each other.
Thanks
Commit when something logical is done or you need to perform an
action on the branch. Push when you have confirmed the code is good
via unit tests. Commits are local, pushes are public.
Branch when you are about to start something that requires
several days or even weeks :-)
Clone when you need to, there are no best practice rules around it.
The mindset isn't about committing often, it is more about merging often. If you are on a branch, merge with the mainline frequently. Smaller chunks are easier to digest and you can keep visibility on what is developing (to adjust your code accordingly).
I'm working on a new feature branch. It's necessary to keep all the history, but for someone scouring over the history at a later date, much of it is over verbose.
For example I may have 5 commits taking through the steps of adding a new database table, its business logic, its validation and some experiments that I change my mind about etc etc. But for a co-developer all they might need to know is "this fixed bug X".
Is it possible to somehow group a set of commits, so that an overview is shown in the log but still being able to view all the history. Not only only my local repo, but the remote repo as well.
I'm guessing that I could have separate sub-branches and merge them as I go along. But I'll only know that I want to group a set of commit retrospectively. So I don't think that is a good route, as I'll have to keep going back and forth.
I can see that there is a group extension but it's unmaintained. And my experience with unmaintained plugins means that usually I'm going the wrong way about it and that there is a perhaps a better technique.
Is there any best practice around achieving this sort of thing?
For what it's worth, I think you're going down the correct route when you say you want to keep all of your history available. You could use the MQ extension to collapse your changesets into a single commit, but - although this would give you a 'clean' commit - you would lose all that juicy detail.
My way of handling this is to develop on a branch or in a separate clone, and when it's going into Production I describe the whole group of changes in the commit message of the merge, i.e. don't just use "Merge" for the commit message :).
I understand your point about only knowing if you need to group retrospectively, but I think as long as you have some rigour around your dev/test/release process then this shouldn't be too much of a limitation.
You want the collapse extension.