[evs] Does EVS remove some of CVS limitations?

Eric B. ebenze at hotmail.com
Tue Feb 5 13:45:24 GMT 2008


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 




More information about the evs mailing list