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.
"Arthur Barrett" <arthur.barrett at march-hare.com> wrote in message news:fo8rt1$k1m$1 at paris.nodomain.org... > Eric, > >> I'm not sure if this belongs in EVS group or EVS-dev, so please let me >> know if it belongs more in the dev discussion. > > I think here is a good place. > >> - tag names to be unique within a branch name-space only. No need for >> tags > > Can you explain exactly the use-case/business-case, as detailed an example > as possible. > We are planning to more formally support the March Hare 'promotion model' > concecpt in EVS. 'promotion levels' are described in the eBook - they are > a branch used not for any actual changes but only for merging: eg branch > dev-maint-1 is used for maintainging release 1 of the software, and there > is a test-maint-1 and a prod-maint-1, equally dev-maint-2 is used for > maintaining release 2 and there is test-maint-2 and prod-maint-2. In EVS > this will be something like branch 'maint-2' and 'maint-2/test' and > 'maint-2/prod' so I think the answer to your question is 'yes' you can > have branch 'test' and 'prod' on both maint-1 and maint-2 - the syntax is > as above. This is not in the current preview - but it is a feature planned > for 'version 1'. I think you have provided quite a practical example. We do something similar here. The trunk of my code is used for active releases only. Consider that version 1. Whenever I need to work on new development, I start a branch for the new dev work. Ex: branch B_1_1 ( for Branch 1.1). Now within Branch 1.1, I know that I am going to have several interim releases (some worked on concurrently) until version 1.1 is ready to be released. So we further sub-branch version 1.1. to 1.1.0.1 (B_1_1_0_1) and 1.1.0.2 (B_1_1_0_2) and 1.1.0.3 (B_1_1_0_3)... when each individual branch has completed its work and ready for QA testing, the code is frozen and released. The changes are then merged (promoted? I think is the term that you use) into the parent branch (B_1_1), and the branch B_1_1_0_1 is then closed (no more active dev on it). The merge is then tagged as T_1_1_0_1 and testing begins. So right now, I am managing fine using our rev numbers for tags and for branch labels. However, this starts to become a nuissance sometimes as they aren't very descriptive. I don't really know what T_1_1_0_1 referes to other than v1.1.0.1. It would be nice to be able to use some descriptive inforamtion instead at times. For example, terms like RC1, RC2, RC3. Other concepts to be used within a particular branch could be TEST, EXAMPLE, etc. The biggest issue occurs when two ppl want to tag independant branches on the same day with a date code. For example: DEV_AT_2008_02_05. If developper 1 tags B_1_1_0_1 with that, then developper 2 can't. So instead, we find ourselves creating longer and longer tags. Ex: B_1_1_0_1_DEV_AT_2008_02_05. and B_1_1_0_2_DEV_AT_2008_02_05. etc. I think it would be nice to be able to enforce unique tags within branch names only, and not have to worry about the namespace of the entire project. Of course, to make this fully effective, I would expect a "search" mechanism would have to be implemented in order to "find" all branches that have a particular tag name, and hence be able to determine which branch you want to use. I believe Perforce limits tag uniqueness within the branch namespace only. >> - Merging of renamed/relocated files to reflect the new name/location in >> the merge > > This is from your previous post. I'd like to see some market assessment as > well as user assessment before going much further - I think you were > checking up on Perforce right? I will check with others I know who are working with Perforce and see how it handles it. However, personally, I find this to be quite a significant issue that would do nothing but break builds and make merges and renames so much more difficult. When merging files in a branch, what would happen when merged? Would they then remain in their original locations? I can't imagine how that wouldn't break every build out there, espcially when you think of web-applications and links and include files, etc. A perfect example for how renames are important are in Java programming. In Java, the class name must match the filename. So for example, a file called TestExample.java would contain a class called TestExample. Furthermore, it's path within my project determines its package. So my src/eric/test/TestExample.java class would actually be referred to as eric.test.TestExample() in my code. If I renamed my class from TestExample to Example, and moved it to src/eric/functional/Example.Java I would be forced to then rename my class obect to Example.java. And then within my code, I would start referring to it as eric.functional.Example(). So when I merge my branch back, if those file renames/moves aren't carried over in some way or another, I would find myself with build errors all over the place, and be forced to figure out which filenames have changes and rename them a second time. This just becomes increasingly difficult and error prone. So the other solution becomes deleting the original file, and creating a new file with the new filename (as we do in CVS), but then you lose the entire history of the file. Unless there is a way to duplicate the history in the new file. >> - LDAP authentication and / or SSO > > CVSNT and EVS both do this to varying degrees... SSPI is SSO (provided > your SSO is Active Directory) and Active Directory is actually a kind of > LDAP - though if you are using a Linux/Solaris/HPUX server then you can > use PAM (provided that your SSO or LDAP has a PAM plugin - which I think > they all do). On the commercial side we've done a few quotes for > supporting some specific LDAP authentication, unless someone contributes > the code I can't see us doing that voluntarily, but we'd happily open > source it after the customer had paid for it. Was thinking outloud re:LDAP support. Haven't actually tried any LDAP integration with my CVS yet - one of my many projects that I will be working on this year, I believe. Was hoping there would be some built-in support, but can always look into some form of PAM plugin. Sorry for the long message. Hopefully it gives some insight into the way others work and use CVS (and hope to improve with EVS). Thanks, Eric