Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gerhard, > So, if I understand that correctly, instead of keeping several parallel > branches (e.g. one for the 3333 development and another one for 3336), you > keep several parallel sandboxes (one where the 3333 development happens > and > one where the 3336 development happens). Yes - that's standard unreserved / distributed versioning - what all CVS users do (only CVSNT supports alternatives like centralised unreserved etc)... > With this update, the final commit under this bugid now contains code > merged in from other bugids. For example, a final commit on 3333 may > contain a halfway done (and not yet working) implementation of the code > for > the new board on 3336 (that works neither on the old nor on the new > board). Yes I pointed out that 3333 and 3336 probably are dependant. The only way to fix that is with a reserved process (or refactoring the code). I suppose you could keep a parallel branch (dev_twinkie_2?) but you'd only perform one merge, down, to dev_twinkie when it is complete and then handle "fixes" thrown up in testing from there... But really if you cannot live with 3333 and 3336 becoming dependent then refactoring the code or using a reserved process is the only way to go. > I think that this has the potential to introduce all kinds of strange and > difficult to find bugs, because you don't really know what you're merging > when running the promotion merges -- unless your bugid commits are all a > single block. Which they usually won't be if all features/bugs are being > developed/fixed on dev_twinkie and developers commit regularly. That > promotion merge will bring in any amount of code that has been developed > and committed independently of 3333, and that also may not be yet complete > or even working. Ahh - but the other smaller changes do naturally tend to be much more atomic. No CM system or process I've seen can handle several large independent changes that affect the same files as each other occuring simultaneously with regular "progress" commits and still keep the changes separate. The "solution" then is always refactoring. It is not a well documented relationship between CM processes and code design, but I've discussed this with several CM professionals and they all agree that the relationship is there, and in situations like this that is the only place it can be fixed*. > Only if their commits actually were "atomic" in the sense that there were > no intermediate commits on other bugids. Again - it doesn't work like that in practice. Usually the change is atomic, and if it is not then the code wont unit test or perhaps it wont even compile, in which case the developer of the smaller piece of code fixes the problem (by rolling out the previous - unwanted - commit). > In my work, this is a very common scenario. It is not always possible to > architect the application according to the needs of the VCS. In general, I > tend to think that the VCS should support the architecture, which in turn > should reflect the project requirements. The VCS is for me not a project > requirement, it is a tool to achieve them. It's a catch 22. It's not really a fault in the tool* it's a limitation of modern CM best practice - the code must be manageable to be managed. There are some brilliant programmers out there that will never get high paying work - not for lack of talent, but because they are "unmanagable" - and it's the same with code - it's not good enough that it works, it must be "manageable"... However as you've described your code and process I do not think it's the case. I agree, it's easy to look at the theory and poke a lot of holes in it, but if you give it a go you will find it works in practice. I can poke (the same?) holes in your current workflow, but that works... Chaos theory... > I'm not sure what you call a reserved process. If you mean file locking, > that doesn't work -- I can't lock all files that are affected by the new > board while the board goes through the testing and pre-production phases. It's not file locking because it only affects the branch you are working on - it's better known as "reserving". And no - you don't normally keep it reserved after development/unit test has completed - however you then get into project management... > That's why we do this on a branch. The branch permits me to make sure I > only merge features that are complete and at least tested and "released" > by > the developer. This is something bugids alone don't ensure -- as Tony > explained. You seem to be using separation of code into files as an > additional tool to manage conflicting commits (in the sense you suggested > with the partitioning of the application); I think that branches are a > more > general and less intrusive tool. Except as has been shown that doesn't work. After I finished off last time I remembered more about the "technical fault" in what you are doing by merging "back" - it isn't a merge (because you cannot merge bi-directionally) it is a copy/replace and you run the risk of losing changes that were not merged in to the branch first. If you are really paranoid you can do as I described above and put 3333 on dev_winkie_1 and 3336 on dev_twinkie_2, but you only merge them back down into dev_twinkie and only once. Note *: Apparently CM types know this is a problem and have been discussing it for years, though it only came to my attention about 18 months ago, and much to Tony's regret I passed the info on to him. The "holy grail" in CM now is a tool that will version something smaller than a file (eg: a line, or a function). I think this is the feature you really want and are trying to describe. Once an SCM tool can version something smaller than the entire file, then the code can be as monolithic as you want because the SCM system understands and tracks not just version 1.18 and 1.19 and 1.16.1.2 and the merges, but it knows that this "changeset" is these lines and those lines within that file. This still wouldn't make the SCM system intelligent, however it would allow the SCM system to be told to construct a view of the project with bug fixes 2 and 3, and also a view of the project with bug fixes 2 and 4. EVS is NOT intended to address this, and unless a LOT of people buy (that's purchase the commercial version...) EVS licenses then it never will be a project I or Tony consider... The reason why noone (not even IBM/Rational who are widely considered the CM kings) has done it is that it's in the seriously difficult bucket (and would require a complete re-training of CM professionals)... Regards, Arthur Barrett