[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: How does arch/tla handle encodings?

From: Marcus Sundman
Subject: Re: [Gnu-arch-users] Re: How does arch/tla handle encodings?
Date: Sat, 28 Aug 2004 23:38:13 +0300
User-agent: KMail/1.7

On Saturday 28 August 2004 18:47, Jan Hudec wrote:
> On Sat, Aug 28, 2004 at 14:24:11 +0300, Marcus Sundman wrote:
> > On Saturday 28 August 2004 13:23, Jan Hudec wrote:
> > > On Sat, Aug 28, 2004 at 04:18:54 +0300, Marcus Sundman wrote:
> [...]
> I really think arch should learn to handle files-as-directories hybrids
> when that interface is finalized in linux. Actualy that tar should learn
> it (which it quickly will when reiser4 gets in mainstream linux) and tla
> should start using that tar. I further assume that tar will support
> translating this format to extended attributes, the sun's "*at" version
> (basicaly the same but with special syscall), microsoft's forks etc.
> Well, we will need a diff for extended attributes, too.

You are probably right, although it should be given much thought before 
committing to any particular plan.

> > > > After giving it a lot of thought (quite a while ago), I concluded
> > > > that I would personally prefer a general filter plug-in system in
> > > > the CMS/RCS. This way the logic can be standardized and
> > > > centralized, moving the burden (and the responsibility) of setting
> > > > up the filters from each developer to the project leader. This way
> > > > you also won't have issues with different people using different
> > > > platforms and/or clients. (Anyhow, this is only my personal
> > > > opinion, and I wouldn't want to impose it on others.)
> > >
> > > Getting quite somewhere else... Would be a nice idea. Though it's
> > > pretty tricky to get that right.
> >
> > I don't see why it would be particularly tricky. Many filtering systems
> > have been designed over the years, and probably quite a few of them by
> > very inexperienced developers. Especially if arch/tla gets an
> > integrated VM then it'd be a piece of cake.
> No, it's not. Eg. CVS got it wrong. You must make sure that the
> filter-cause differencies won't cause conflict on merge and that they
> won't clutter up diff output. Thus you need to run the filters in quite
> many commands and you need to be careful to choose the right place in
> each of them.

I was talking about the actual filtering, not the integration with the 
RCS/CMS. You are correct that it might be a bit tricky to get the whole 
thing right, but I don't think it's really that hard if you sit down and 
think about it for a while. (It's no surprise that the CVS people got it 
wrong. They got most things wrong. I don't think they ever thought about 
anything but the next feature in the pipeline.)

- Marcus Sundman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]