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.
Tony Hoyle wrote: >>This was when you accidentally mix up vendor branch and release tag on >>import. This does not seem to be what is happening here, though... > > No, but the cause of it was the lack of checking for an existing > vendor tag. No, the cause was the lack of checking whether the given release tag already existed (doesn't matter if it's as a branch or regular tag). > Import still isn't particularly error checked but it's > harder to stuff things up now (I just realised the release tags aren't > checked either). This alone should have sufficed AFAICT. Of course, then there's the other issue with Import apparently being hardcoded to always use the 1.1.1 branch regardless of the given vendor branch name... Therefore you /must/ check the given vendor branch name indeed - and only allow it if it either *matches* the name of the existing branch specified by the -b option (implying -b1.1.1) or if there is no branch off the 1.1 revision at all yet! A better and more consistent (and less complex) solution IMO would be if using a non-existing vendor branch tag actually caused the creation of a new branch (I'd suggest using odd numbers as the third figure, e.g. 1.1.3, 1.1.5, etc.). Sorry for dragging this on, but I really do think that disallowing reusing of vendor branch names was an unnecessary change at best. In the light of Phil Richards' recent observations it even appears to me that it is actually making matters worse than before... Cheers, -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)