CODEWITHSUNDEEP
version-controlmercurialdvcsbranching-and-merging
hrehfeld
hrehfeld

Reputation: 481

hg: propagating changes to n times two equally important branches

I know similar questions (regarding "cherry-picking") have been asked before, but I haven't really found a satisfactory solution to my problem. Most answers seem to assume there's one base revision that you can branch from to implement changes -- which I don't really have -- so I'm not sure what the correct way to setup my repository/branching is.

I'm creating frameworks for a lecture that the students can use in their assignments; there will always be the version that the students receive, and the correct solution. These two are equally important, none of them really is "the main branch". Also, the students receive a different iteration of the framework for each assignment, slowly adding features to it in each assignment.

Basically:

Where each assignment is a superset of the previous assignments, with minor modifications to the files of previous assignemnts.

What's the ideal repository/branching setup/workflow so that I have easy access to the different iterations and versions of the framework, and so that I can easily propagate changes to the framework to all other branches?

Use-Cases:

Upvotes: 2

Views: 118

Answers (2)

Laurens Holst
Laurens Holst

Reputation: 21036

Seems like a setup that Mercurial is well equipped to handle. I would maintain a simple base repository with the assignments where you tag the increments. You can make only the part up to the current assignment available by pushing just those parts to the public repository. Then all students can clone (fork) it, and when it is time for a new assignment just tell your students to pull and merge in the changes from the next tag.

So effectively every student’s clone is a branch, and the changes are propagated by making them on the base and then merging them forward. If there are conflicts the students will be better suited to handle them since they know their code and the changes they made. (Although they might not be so familiar with version control and conflict resolution, but I guess the point of making them use Mercurial is to teach them.) I wouldn’t push changes to the students.

An attempt at a visual representation:

                  o -- o -- o [solution1] ------------------ o [solution2]
                 /                                          /
Base: o == o == o [assignment1] == o == o [assignment2] == o == o [assignment3]
                |\                      |\
Student 1:      | o -- o -- o ------------o (merge) -- o
                \                       |
Student 2:       o -- o -- o -- o ----- o (merge) -- o -- o

I think solutions should be branching off the assignments just like the students do. After all, they’re essentially all solutions, just this particular one has an official stamp of approval. Another reason to branch the solutions off is because they would otherwise massively conflict with the students’ changes.

Do note that as changes from the student branches are never merged back (that wouldn’t really be possible), the odds for conflicts increase with each assignment. So you should probably try to keep your code and the student’s code as modular as possible, this will decrease the likelihood of conflicts.

Upvotes: 0

Paul S
Paul S

Reputation: 7755

I think what you've really got is a situation where each assignment is a branch, each one being forked off the previous assignment.

-- assignment 0 -----
                 \
                  \-- assignment 1----
                                   \
                                    \-- assignment 2 ----

Any change / bugfix that you make would be made to the earliest assignment branch that it applies to. It would then be merged forward into any later assignments.

-- assignment 0 ------------------------------------------
                 \
                  \-- assignment 1---- bugfix -------\----
                                   \                  \
                                    \-- assignment 2 --M--

I think tasks and solutions would be intermediate steps between the assignments. (Possibly tasks & assignments are actually the same thing)

-- assignment 0 ------------------------------------------
                 \
                  \-- task 0 -- \ ---------------------------
                                 \              
                                  \-- solution 0 -- \ --------
                                                     \
                                                      \ -- assignment 1-------

It's going to take some work because you'll have quite a lot of merges to do for any change, but effectively you have a large number of release trees. With release trees the process is that you fix a bug in the earliest branch you can and merge it forward. No difference here.

Upvotes: 2

Related Questions