Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] what does "Fixing file not in standard form :" mean?

On Wednesday 24 July 2002 08:03 pm, Florin Iucha wrote:
> On Wed, Jul 24, 2002 at 07:11:30PM -0400, Mark C. Chu-Carroll wrote:
> > On Wednesday 24 July 2002 05:03 pm, Florin Iucha wrote:
> > > Hello,
> > >
> > > I am adding a bunch of files to a project and I'm getting tons of:
> > >    Fixing file not in standard form : /path/to/file
> > >
> > > What does it mean?
> >
> > It means the file ends without a carriage return on the last line.  Each
> > line of a text file is supposed to have a carriage return at the end.
> > Stellation normalizes text files if they don't have a CR at the end.
>
> 1. Then the message should be explicit and tell me what it does.

We thought that's what it's doing. Standard form for text files
is a carriage return on the end of each line. I thought that was
a reasonably good message for what it's doing. Would it be
better to just say "Adding carriage return to normalize text file"?

> 2. I still don't think it is proper to change a file without asking me.

It's only adding a carriage return. Which it does for a reasonably
good reason.

> 3. Why shoult Stellation care about the contents of the file? For
> merging?

Actually, for slightly more than that. Stellation uses an internal
storage form called in-place-delta. In IPD form, each line is
stored separately. When regenerating a file from checkout, it
terminates each line with a carriage return. So you'll always get
a carriage return at the end of the last line on checkout.

If we don't normalize files on checkin, then you end up with the
rather unpleasant problem that doing a diff between a checkout
and the original directory will generate a bunch of diffs to make up
for that added carriage return. 

Now, we could add a way of storing whether or not a text artifact properly 
ends in a carriage return.  

One way of doing it would be to store the carriage return in the
line in the storage format. We certainly could do that. But doing that
has its problems. Alternatively, we could have an entry in a table somewhere
indicating whether or not a text artifact ends with a carriage return.

I don't find either option particularly attractive. And so far, it
just hasn't seemed an important enough thing to worry about.

If you think it's really important, it's not a terribly hard thing to do to
fix it; it's just one that's never really concerned us.  We've taken the
viewpoint that since it's a standard format convention that text files
end in carriage returns, there's nothing wrong with normalizing them
if they're not, and that doing that is preferable to adding extra 
complexity (even minor complexity) to the database.

	-Mark
-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx




Back to the top