[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking functional spec: read-only WC

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2004-10-14 15:37:43 CEST

"Ph. Marek" wrote
> > to produce a merge tool for every imaginable file type, in practice
> > people don't have them, which is why they want locking.
> That's true. But I don't think you're able to modify MSWord-Files
> Microsoft Office (or KOffice, or OpenOffice, etc.) ... so it seems
> to have the tools that are needed for my work available.

Editing and merging are different. I can edit any text format file with
notepad, but non-trivial merging (which is where I started out) is

> If I need a special program to edit file X (image manipulation, some
kind of
> office, ... even .tar-files would be possible) AND I'd like to do
> controlling AND I'd like to have parallel editing THEN I'll need some
tool to
> merge, or I'll have to do the merge by hand.


> I'm aware that it won't be possible to have every merge program
> everywhere ... all I'd like to get through is there should be a
> to call external programs depending on the mime-type for merge and

> BUT: I need some tools to modify some data - I *should* be allowed to
get the
> corresponding merge tools, if there are any.

So what you are asking for is a client-side config file which determines
the merge tool to use, based on mime-type. Isn't that a separate feature
request? I don't think it affects the arguments about locking

> Locking is needed - for file-formats which have no merge tools
(installed), or

Agreed. All I was saying was that some text files which can normally be
trivially merged automatically without any special merge tool (C source,
xml, text, etc), are difficult in *some* circumstances. And in those
cases, locking would be useful, but hard to implement as a

>... possibly we could burn the "don't
> modify tags"-problem here too - just lock
> the /tags/xxx-directory-tree ... :-)

... and that is another story ;-)

But I think we are making a lot of noise on the dev list without
actually contributing much to the problem in hand ;-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 15:44:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.