Repository history predating 2010 (pre-Git?)

[phil-blain]

Hi, I was looking for the reason why ncdump does not print newlines in its output when it encounters them (e.g. in attribute values) when the file type is netcdf-4. I'm talking about this code in ncdump/ncdump.c::pr_att_string:

netcdf-c/ncdump/ncdump.c

Lines 438 to 446 in 0c6fd78

	case '\n':
	/* Only generate linebreaks after embedded newlines for
	* classic, 64-bit offset, cdf5, or classic model files. For
	* netCDF-4 files, don't generate linebreaks, because that
	* would create an extra string in a list of strings. */
	if (kind != NC_FORMAT_NETCDF4) {
	printf ("\\n\",\n\t\t\t\"");
	} else {
	printf("\\n");

So I did git log -L:pr_att_string:ncdump/ncdump.c to get the history of the function, but this code predates 18f4bca (moving to trunk subdir, 2010-06-03) where ncdump/ncdump.c was added to the Git repository.

Is the history pre-2010 available somewhere ?

[akrherz]

Is the history pre-2010 available somewhere ?

This Unidata blog post denotes the subversion legacy was retained, but I don't think the CVS one ever was nor have seen a copy of that in the wild, maybe my memory is failing. Googling found this repo directory with ancient netcdf stuff included, maybe that would help your investigation?

[WardF]

@akrherz is correct, the migration from CVS to subversion was before I joined Unidata; one of my earlier tasks was to manage the migration from svn to github. What information are you looking for? I presume an explanation beyond the one provided in the comments re: \n. @edwardhartnett is responsible for the implementation of netCDF-4 (Thanks Ed!), he may have some insight if you have additional questions.

[phil-blain]

Thanks, yes, I'm curious as to what was the problem that led to this change. "would create an extra string in a list of strings" is not so clear to me. So I was hoping that the SVN commit log might have more information :)

I'm not sure if it is related, but if I use cdo showattribute test.nc on a file with newlines in an text attribute, I get a SIGABRT in glibc with "corrupted size vs. prev_size" ...

[phil-blain]

... that is, if it's a netcdf-4 file.

[phil-blain]

OK, it seems the cdo bug is fixed in the latest (2.3.0) version .

[DennisHeimbigner]

I think the argument is more or less this.
NetCDF-4 added a "string" type. Before that (netcdf-3 and variants) only had "char" type.
In the netcdf-3 case attribute values can be strings of characters that are concatenated to produce
the final sequence of character values. In this case, printed newlines would not affect the concatenation result.
For netcdf-4, a string type attribute's value is also a sequence of strings, but they are not concatenated.
So adding lines apparently causes the output to look like there is an extra string hence the count of the attribute's
values is one too big.