ctm(1) deprecation in the FreeBSD base system?

Montgomery-Smith, Stephen stephen at missouri.edu
Mon Dec 24 15:34:11 UTC 2018

On 12/24/18 3:32 AM, Julian H. Stacey wrote:

> I see a discrepancy using ctm to extract, between ctm
> built on 9.2-RELEASE & ctm built {from both src or ports} on current.
> Just the 9.2-RELEASE ctm does not create 3 zero size files:
> 	base/db/rep-cache.db-journal
> 	doc/db/rep-cache.db-journal
> 	ports/db/rep-cache.db-journal
> All 3 trees contain 15 other zero size files, so presumably the
> discrepancy is not to do with zero size files as such.
> All 3 trees have no other files called rep-cache.db-journal
> I created 3 new trees with
> 	ctm -q /pub/FreeBSD/development/CTM/svn-cur/svn-cur.07300xEmpty.xz
> on all of { 9.2-RELEASE & ctm built {from src and ports} on current }
> All 3 trees are the same, with all 3 rep-cache.db-journal
> Then upgrading to svn-cur 7307 with
> 	ctm -q /pub/FreeBSD/development/CTM/svn-cur/svn-cur.07[0-9][0-9][0-9].xzthe 2 trees on current had identical file lists with all 3 rep-cache.db-journal
> But again the tree in 9.2-RELEASE no longer included the 3 rep-cache.db-journal
> Anyone know know if the discrepancy indicates something amiss with ctm ?
>   (rep-cache.db-journal presumably from SVN, maybe older & newer CTMs
>   have some different understanding that data i delivered from SVN ?
>   seems a bit dodgy that, I'd have thought best if CTM had no knowledge
>   what delivered its tree.)

For these kinds of files, ctm is merely a wrapper around the "svnadmin"
command.  The diffs are created using "svnadmin dump", and applied using
"svnadmin load".  So the discrepancy is in how the svnadmin command works.

My guess is that it is a coincidence that these files are created in one
situation and not another, and that this doesn't effect the actual data
stored in the svn repositories.

But I don't know enough about svn to give an authoritative answer.


More information about the freebsd-current mailing list