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. Thanks, Eric