[evs] Does EVS remove some of CVS limitations?

Gerhard Fiedler lists at connectionbrazil.com
Tue Feb 5 12:51:16 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 wrote:

>> - tag / branch names to include all characters, including spaces and 
>> punctuation.
> I'm not really sure this is a good idea - but there is no limitation I
> am aware of (except maybe we haven't taken account of 'spaces'. What are
> other peoples opinion on this? I definitely think supporting Japanese
> and Chinese branch names is a good thing and the model supports it
> though we don't intend 'internationalizing' things until after version
> 1...

I've never found the limitation in choice of characters to be a problem. It
takes a bit to get used to, though :)  OTOH, using proper command line (and
database) quoting of the name, there doesn't seem to be much of a reason to
restrict the choice of characters. 

>> - Ability to add comments / description to branches / tags
> I'm pretty sure the data model supports this, but I'm not sure if the
> EVS client has a parameter for it.  It'd probably be 'easier' to
> maintain from the server interface than a client (hopefully more on the
> reason why in a month or so).

This would be something I'd welcome. I often have my own "meta data" files
where I keep notes on certain tags and branches, and it would be nice to be
able to have that meta data where it belongs -- with the tag, in the repo
meta data. My vision of that is an additional -m parameter to the tag
commands, just like it exists for the commit commands, with similar ways to
edit it later. 

One question is how to deal with that when different tag commands with the
same tag contain different descriptions... append it, or replace the
previous entry. Maybe prompt the user about what to do, and maybe also
prompt for a description if no -m option is given and no previous comment

>> - 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've already stated that I can't see this not making sense; after all, not
merging the renames is guaranteed to break any standard build system, so in
most cases this would have to be done manually if it isn't automated. I
can't see how this fits into what I understand of your "safe use" policy
towards repositories and merges.

A discussion scratching the surface of how ClearCase and Perforce deal with
the issue:
It indicates that Perforce doesn't handle renames well at all, whereas CC

More information about the evs mailing list