Re: [Gnu-arch-users] missing feature: text file handling

[Zenaan Harkness]

On Fri, 2004-10-08 at 12:59, John Meinel wrote:
> Stephen J. Turnbull wrote:
> >>>>>>"Adrian" == Adrian Irving-Beer <address@hidden> writes:
> > 
> [...]
> 
> > arch should provide binary semantics for objects it manages,
> > attributes for each object, and a way to plug in an attribute-
> > dependent codec on the client.  Toolchains/platforms/projects should
> > provide their own codecs, which the arch project could accept as
> > "contrib" and maintain a library, but should not "support" as part of
> > arch.
> > 
> > Support for the codec library as a related project is up to the arch
> > maintainers, and would be desirable.  I'm just saying that a project
> > using arch should decide what the archival file format should be, and
> > arch should serve those files up byte-for-byte identical to the
> > archive content, until it gets to the codec.  After that it's up to
> > project policy, and mistakes in codec usage aren't arch bugs _by
> > definition_.  Separation of responsibility and all that.
> > 
> 
> I agree. I prefer arch to give me back the same file I gave it. And 
> layer on top of that the semantics.

Very strong agreement here.

> For instance, it would be possible 
> to have a pre-commit hook that would go into the newly formed ,,commit 
> directory, and change all the .patch files to remove CR/LF, and have a 
> post update/get script that would add CR/LF back. You just have to take 
> a lot of care to only do the correct files.

Thought should really be put into a tie in with the "encoding" thread
that happened a little earlier. Eg. can CR/LF choice be expressed in
terms of an "encoding" (eg. ISO-8859 etc), or is it in addition to the
encoding. It's definitely more meta-data.

> That's why the precommit hook script just refuses to commit if a file 
> endings are not what it likes. You can always change it's mind, or you 
> can go run dos2unix/unix2dos/whatever to make it run correctly.

This is reminding me of how PostgreSQL does encodings - it's a
per-database (archive) thing there, probably because indexes and things
depend on the encoding format.

> Is this good for anyone who runs tla?

Consistent storage format, defined meta data format and hook/ conversion
"layering" is not useful to tla users?

> Probably not, but for people like 
> me, it's really what I prefer. I like being in control, and knowing that 
> arch won't mess with my files. What I give it is what I get back.

Perhaps "arch won't violate defined Archive Invariants". How could
anyone disagree with that concept?

It would be great to be able to know that any attempts to commit files
that violate the invariants will throw an error, which must be manually
overridden to bypass.

Eg, perhaps a "file extensions hook" could "ensure" files ending in
[.jpg|.gif|etc] are always committed as 'binary'.

> I guess I've just been bitten by someone checking a CR/LF file in unix 
> mode, and then the checkout has all CR/LF/LF, not pretty.

Agreed.

> That, or someone forgets to set the binary flag, and checks in a .png 
> file. Again, not something that comes out correct on the other side.

I think we have pretty good agreement in this thread, and we're
just discussing approaches.

cheers
zen