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.
Eric, > Late identification also won't address other interpreted languages (such > as HTML) where filenames / locations are critical to proper functionality. Yes - I saw your other post on that topic. In my experience and supporting all our suite/pro customers (a lot of whom use CVS Suite for managing web sites) this is not a problem in practice. Web developers don't make a habit of renaming files - it's a killer for a web application because as soon as a web site is live people start bookmarking URL's and to change them is a kiss of death. In theory you are right - but in practice wrong. > Is there a thread somewhere that I can catch up on this conversation? It was on comp.software.config-mgmt - it'll depend on how long your news/nntp provider archives it for how far back you'll be able to read. The thread started out as ' Branch yes, merge no' with my first post on about Nov 6th 2007 and changed to 'what differentiates SCM from VC' around Nov 8th 2007 and changed to 'Specs for future SCM' around Nov 10th 2007 and then there were a few branch discussions from there. comp.software.config-mgmt is a tool agnostic newsgroup - great for discussions about SCM in general or SCM methodology - though a working knowledge of clearcase is often assumed. If you are from a technical background like me the language used can seem at times quite a hurdle - but patience and politely asking for clarification is always responded to positively by the old-timers. The newsgroup is archived on google: http://groups.google.co.uk/group/comp.software.config-mgmt/topics?hl=en&lnk=gschg As with most web based news readers the search and threading functions are pretty broken so I wont attempt to link to the discussion directly, but you can do a search for the subjects specified and you'll get a rough list... > Forgive my lack of knowledge, but what is clearmake and how does it relate > to the issue? Clearmake is part of the IBM ClearCase build system: I'll not even attempt to answer your question in detail - see the above thread if you are really really really interested. Suffice it to say that until there is an decent open source build system (better than clearmake hopefully, since noone has touched a line of code in that for over 10 years, and it doesn't support Java) that there are some business 'problems' that we just can't really solve well for an organisation. > I'm not entirely sure what "late identification" is, but I really don't > see the Java spec changing anytime soon. Agreed - since it was Marc I just wanted to be clear to him that I understood the theory. I thought I was pretty clear in saying that we need a pragmatic solution since the chances of a change in javac is slim. > The whole concept of class /file naming is pretty much a building block > for the language, and while it seems incredibly strange to non-Java > coders, once you get into it, it actually tends to make things a lot > easier to work with. Coming from a C/C++ background myself, I found the > whole concept incredibly bizarre when I first started in Java, but soon > got quite accustomed to it. It is a case of the language imposing a > certain organization and structure to the coder. > Yes that's all well and good - but the people who implemented it did not think about the impact on build, test and deploy (ie: SCM). To come up with a new language spec in 'modern' times and never think about what it'll be like to manage in a large project was negligent. Marc is spot on - the compiler/build system should use late identification. But you are also spot-on: we can't wait for that to happen and must come up with some suitable support in the meanwhile. Furthermore a decent open source build system needs to be built that can 'work around' this negligent engineering in Java to provide a decent SCM in a Java environment. ie: management need to know which release candidates of the java app use eric.functional.Example and which use eric.test.TestExample, which changesets (bug1234, bug1235, bug1236) rely on which class etc, and finally they should be able to schedule new builds using codebase B_1_1_0_3 with either. We can do all this in CVSNT for C/C++, Pascal, Fortran, SQL*Plus, Uniface, Ada, COBOL, MASM and pretty much any language other than Java, but the solutions in CVSNT take time to put together and are not as 'obvious' (or inuitive) as they are in ClearCase - A lot of EVSMANAGER is about fixing the lack of 'obviosness' of the current solutions, and we are hoping to release something of our own solution to the build issues (including Java) late in 2008 or early 2009. I think this has gone completely OT though - there isn't a decent SCM build solution for Java and wont be for some time - that is not EVS's problem (or better said: it is not the problem that EVS was designed to solve). You are right though that EVS needs to support the Java programming methodology which effectively implies the need to have an option to propagate renames with a merge. I think an 'ideal' soltution would be able to specify a default by file type (so for instance .java files could rename and merge, but .c/.cpp files would not - but that's probably just overkill on a project that is already late...). Regards, Arthur Barrett