Re: Some questions...

Ben Collins-Sussman wrote:
> Wait, hold on. Nothing is preventing you from using unicode .java
> files. Your problem is that you're using an unmergeable encoding,
> like UCS2, or whatever. Why not just use UTF8 source files instead?
> Then you get normal, mergeable text.

Unfortunately the in-house tools are all native Unicode, and I can't
change that.

There's no reason why UCS2 can't be mergeable... cvsnt does this already
in exactly the way I describe - it works well (never had any negative
feedback on it, anyway).

> This subject has never been brought up before; I wasn't aware it was
> Subversion's responsibility to deal with every possible unicode
> encoding. You make a good point, though. Subversion definitely

There's only a few, really, from the point of view of source control.

Text - basically anything you can use strlen() on or printf() etc. This
includes pure ANSI and UTF8... MBCS fits this, too.
UCS2-LE
UCS2-BE -- UTF16 is just an instance of UCS2 for the purposes of storage.
UCS4-LE
UCS4-BE

UCS4 is less useful (I'm currently unaware of any system that actually
uses it).

UCS2/UTF16 is extremely common in asia, where they're pretty much forced
to use it or be stuck in codepage hell.

UTF8 is the lowest common denominator for all the UCS/UTF encodings...
you can go back and forth without losing any data.

> *could* grow a new "svn:encoding" property, convert encodings to UTF8
> for mergeability, and convert back. It would be a bit of work to
> write this feature, but nothing horrible.

It's probably relatively trivial.. there's already a lot of translating
going on.. cr/lf, stripping keywords, etc. It's just an extra call.

> Still, it still feels like a post-1.0 change to me. Not high priority
> at the moment.

I'd write it myself, anyway, since it's a priority for me :)

I need to make at least my copy of subversion do everything cvs does for
me at the moment, before I'd consider changing. A lot of the stuff can
either be done with scripts or outside the main tree, but some of it
just needs a code, unfortunately.

Mergepoint handling is my next big beef, but you guys already plan to
add that so hopefully it won't be long (we maintain two branches and
merge daily between them... without mergepoints that wouldn't be practical).

Speculative branching I could live without - it's surprisingly useful
but I suspect it's not going to be compatible with the way SV handles
its repositories.

Tony