I haven't personally done it. We have used it on projects that I have been on though.
However,
-the end goal was simply to build on pre-existing code in a new direction, we weren't really doing concurrent development.
-the branch wasn't accomplished through the labview project. We branched using the p4v GUI.
-the merge utility for LV is a pain and I never have used it for a large project. With this in mind we might have been better using a label instead.
What problems did you hit?
Hi Jesse,
I don't really have a problem for the moment...
I wanted to set up a design process which could give the possibility to :
* have a main (trunk) development, for all test benches
* every new test bench is a branch from this trunk
* at the end of a development of a new test bench, identify features for reuse, and integrate them into the trunk for future developments
* identify bugs corrections or improvments in the trunk and propagate them to existing branches (test benches)
My impression is that the structure with the LabVIEW project, which memorizes paths of files, may be an obstacle to this process. Maybe I should design a process more in line with LabVIEW structure ?
What is your opinion ?
BR
Philippe
If it's like Subversion it's really easy, since the branch only exists in the database. In subversion you create a branch and all checkin/outs will be towards that branch, until you merge it to trunk. It then compares versions to trunk as any other checkin.
/Y