Github is actually my weapon of choice for version control. To be honnest, I’m far to be a pro but I’ve read quite a few pages of documentation, try to use it for two different project and participate to the addon pack.
The latest project we started contained two branches, one for me, one for my partner. We share the same empty folder structure and we have only one common root patch. After working several days, it was time to merge our branches to the Master. And here comes the problem…
Conflict, error… impossible to merge anything and hard to reproduce those problem to understand what was happening. It just didn’t do it and as I’m not really use to the command line yet, hard to say now were is the bug (I’m learning it, I promise).
So my question is, how do you guys manage to use github with lots of patch, subpatches etc. and several guys working on the same project with branches, merge etc… I’m not talking about this : http://nvie.com/posts/a-successful-git-branching-model/
which is more from a strategy point of view. But I’m trying to open a discution about how to use github well while it’s not really designed for XML file and vvvv is a graphical programming environment.
I know some of you are making massive project with massive patch, I guess in such a case the version control has to be done carefully. If we could share some tips and tricks here, that would be really useful, because I believe that a good organisation is the key to create good project.
GH4W (GitHub for Windows) is the obvious choice for us graphically focused types. GH4W is very good for backup of projects, switching branches to either see what other team members are doing or to create your own experimental branches (the rollback command has not been very good to me… I’d be interested to hear other people’s experience of this).
There is no merging in GH4W and I do not see why the GH team would want to produce something specifically for graphical programming languages as it’s too specific. If we wanted a merge tool for vvvv it will have to come from the community whether it’s funded or programmed.
Having talked with Clone and Almost about creating a merge tool the best idea would be to create a program that shows both the patches you wish to merge next to each other. Nodes are then selected using the mouse on one of the patches, these nodes are then merged across.
Definitely a diff and merge tool would make all the difference when using VVVV with Git. Sure it’s possible to do a text merge on the XML source but I wouldn’t wish that on anyone :)
Merging is so important for a concurrent working flow, it’s something you’ll never know you needed until you use but it really does beat the pants off “hey, don’t work on that patch while I work on it!”.
but, please make no side by side thingy, but an overlay one - for example: green nodes = mine, red nodes = theirs and standard grey nodes = equal. the same could work for the pins, too.
was that understandable?
Feel free to call me a reet git but I always try to stick to the nice, throb-free gui for windows - http://windows.github.com/ or the web interface and try to structure the project so that programmers can work on their respective modules. Always trying to avoid spending time on version control when I could be spending time on vvvv ;)
That said a nicely designed difference engine like gaz suggested could save a lot of hassle when there’s no alternative!
use github well while it’s not really designed for XML file
that’s a kind of misleading statement. git is designed to work well with text-based file formats, and XML is one. what it does not work well is binary files, as it can’t compress/diff them properly, but this does not affect vvvv patches, except for assets you include in your patches.
what leads to problems (and to the perception that git and vvvv don’t play well together) is the fact that the user/developer only works with the “interpreted” xml file (i.e. the patch in vvvv’s gui), as opposed to the source code itself. so if two people each work on a certain node, and one moves it to the left, the other to the right, this of course leads to a merge conflict - both changed the same spot in the code, i.e. the coordinates of the node in the xml file!
what can ease the pain of resolving merge conflicts considerably is using a graphical (will say GUI-based) diff tool which shows you the changes in a nicer way than the plain console output. On linux i use KDiff3 (which is surprisingly also available on Windows), I don’t have experience with any other programs which run on windows.
Until user almost comes up with his patch-based compare tool (which sounds awesome btw, but I guess it will be quite complicated to implement properly), this is probably the least-painful way to resolve merge conflicts.
The easiest way of course is to avoid merge conflicts altogether, e.g. with some patching discipline between the different developers (“please don’t touch that subpatch for a while”), merging often, and following git principles (“commit early, commit often”). git-scm.com is about the best homepage there is to learn about using git, take a look! :-)
sebl: yeah, that sounds about right. I think it would probably end up with multiple views in the same way that the Github image diff tool does. Some problems are going to be much clearer as an overlay whereas for others a split view will be the only way that allows you to tell what’s going on.
@fibo, that is a very nice tutorial and great concept!
If a user asked me the best approach to learning how to use GitHub with vvvv I’d recommend GH4W as it’s fairly straight forward to understand how GitHub works, the best folder layout etc.
vvvv-patches looks best suited for patchers that want a quick way to commit from vvvv to save time switching between programs.
@bilderbuchi, thanks for the information. I’ve experimented with merging branches and each developer sticks to their own section then GitHub will merge. It’s then a case of one dev connecting up the root patch. So still some manual work, but good to know this is possible!
