[evs] Does EVS remove some of CVS limitations?

Eric B. ebenze at hotmail.com
Tue Feb 5 13:49:22 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.

"Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message 
news:1t1dnm50x6z5q$.dlg at connectionbrazil.com...
>>> - 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.

Really??  Wow - I am always struggling with using _ to replace spaces and 
dots and everything.  My tag names end up being quite ugly and sometimes 
difficult to read.  I would love to be able to use punctuation in my 
tag/branch names.  Ex: v1.1.0.1 or Dev at 2008-02-05 etc.  Instead of always 
being forced to use _ for every possible punctuation value.

>>> - 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.

I just posted a long blurb about this on my previous reply to Arthur.  I 
agree entirely with you; I think it only makes sense to carry forward moves 
& renames, and is incredibly error prone not to.  Or at the very least, to 
indicate to the user during the merge process that a name change had occured 
and offer him the ability to accept / reject the move / name change.



More information about the evs mailing list