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 exists. >> - 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: <http://maillist.perforce.com/pipermail/perforce-user/2006-June/018834.html>. It indicates that Perforce doesn't handle renames well at all, whereas CC does.