Hi,
I installed Darcs a few days ago and are toying with it. I dont know you but I usually like to work in two or three features in parallel. My problem cames when modifing the same file, then, when push over main repository, darcs say there are conflicts.
Is there any way, good practices, or tricks which let you modify the same file over? How do you usually work in parallel?
FS
Working in new features in parallel
Moderators: hgm, Dann Corbit, Harvey Williamson
-
Kempelen
- Posts: 620
- Joined: Fri Feb 08, 2008 10:44 am
- Location: Madrid - Spain
-
Gian-Carlo Pascutto
- Posts: 1243
- Joined: Sat Dec 13, 2008 7:00 pm
Re: Working in new features in parallel
branches?
-
ilari
- Posts: 750
- Joined: Mon Mar 27, 2006 7:45 pm
- Location: Finland
Re: Working in new features in parallel
To expand Gian-Carlo's answer a bit, you should probably create a separate branch for each major feature, based on the head of the master branch. I don't know about Darcs, but here's an example of my workflow with Git:
1. Create branch A for feature A
2. Create branch B for feature B
3. Checkout (switch to) branch A
4. (in branch A): Write some code for feature A
5. Stash any uncommitted changes (in branch A) and checkout branch B
6. (in branch B): Write some code for feature B
7. Feature B is done. Commit the changes in branch B.
8. Checkout branch A, apply stashed changes and finish feature A
9. Feature A is done. Commit the changes in branch A.
10. Now we still need to get the commits from A and B to the master branch
11. (in branch A): Rebase branch A to "master", in case master has changed while I developed feature A.
12. Resolve any possible merge conflicts.
13. Checkout branch master
14. (in branch master): Merge branch A. This should go cleanly without any conflicts.
15. Checkout branch B
16. (in branch B): Rebase branch B to "master", which now has feature A.
17. Resolve merge conflicts. If A and B changed the same files, you're likely to get conflicts here.
18. Checkout branch master
19. (in branch master): Merge branch B. Again, this should work without conflicts.
20. Done. The master branch now has features A and B committed.
That looks like a lot of steps, but it's a lot more convenient than manual revision control.
1. Create branch A for feature A
2. Create branch B for feature B
3. Checkout (switch to) branch A
4. (in branch A): Write some code for feature A
5. Stash any uncommitted changes (in branch A) and checkout branch B
6. (in branch B): Write some code for feature B
7. Feature B is done. Commit the changes in branch B.
8. Checkout branch A, apply stashed changes and finish feature A
9. Feature A is done. Commit the changes in branch A.
10. Now we still need to get the commits from A and B to the master branch
11. (in branch A): Rebase branch A to "master", in case master has changed while I developed feature A.
12. Resolve any possible merge conflicts.
13. Checkout branch master
14. (in branch master): Merge branch A. This should go cleanly without any conflicts.
15. Checkout branch B
16. (in branch B): Rebase branch B to "master", which now has feature A.
17. Resolve merge conflicts. If A and B changed the same files, you're likely to get conflicts here.
18. Checkout branch master
19. (in branch master): Merge branch B. Again, this should work without conflicts.
20. Done. The master branch now has features A and B committed.
That looks like a lot of steps, but it's a lot more convenient than manual revision control.