Conversion to SVN

[Doug Barton]

On 10/07/2011 14:15, Gavin Atkinson wrote:
> On Fri, 7 Oct 2011, Rene Ladan wrote:
>> Op 07-10-2011 16:13, Ulrich Sp?rlein schreef:
>>> it looks like I'm not the only one thinking about moving the doc/www
>>> repos from CVS to SVN, and other people actually have not only thought
>>> about it but already played around with conversions.
>>>
>>> gavin did some preliminary conversions and it turns out that we end up
>>> with ~50k revisions and about 650MB of changes (IIRC). There are also
>>> lots of weird branches, so perhaps we could size that down a bit.
>>>
>>> What I, personally, would like to see is us using the same svn repo as
>>> src. That means we would have to stop svn.freebsd.org for the
>>> conversion, turn off email sending, dump 50k revisions into it (under
>>> /doc and /www perhaps? where should branches/tags end up?), then turn
>>> everything back on.
> 
> The more I think about this, the less I like the idea.  I really don't 
> like the idea of having revision numbers which no longer increase with 
> commit date (i.e. having revisions 1-250,000 correspond to the existing 
> src tree, 250,000-300,000 being the imported doc tree, and then the 
> combined repo being 300,001 onwards).

I'm sorry, I don't understand your concern here. The commit ids
increment monotonically in svn, and the number is global to the whole
repo. Given that the individual files won't be increasing to a
deterministic value, I don't understand why we care what the actual
number is.

> I think it is much nicer to have two separate repositories, in which 
> revision 1 corresponds to the start of each tree.  I don't see any real 
> advantage in combining them now, to be honest.

I'm still not sure I understand this, sorry. :)

> Combining doc and www more closely, however, I do see the benefit of.  
> However, currently we don't (and have no need to) branch the www tree with 
> each release.  If we combine them, we would be - even though we probably 
> don't wish to.

I think we should give more thought to the structure. I'd like to see
one doc/ directory, with what's in doc and www now both. But we may need
to think harder about what parts we may want to branch, and what parts
we don't.

>>> I haven't really thought that through to the end, but setting up a
>>> separate svn repo just seems silly to me and is another administrative
>>> overhead. ports might be special enough (due to sheer size) to justify a
>>> separate repo/machine, but not doc/www.
> 
> It may actually be easier, as all the infrastructure from the src repo can 
> possibly be reused easily.  Combining them may be harder as more work 
> would presumably need to be done on sorting out ACLs for src and doc 
> committers, etc?

Effectively the administrative separation that we have now is on the
honor system, and it's worked well ever since we branched the original
CVS repository. I don't see any reason why that wouldn't continue to work.

>> If possible, I would like to have one SVN repository for both src and
>> doc/www so that user and project directories can be shared so that there
>> is only one /user/rene.
> 
> An argument could be made that by keeping them separate then it reduces 
> the overhead for people wishing to contribute.  People wanting to commit a 
> kernel patch need a copy of the website on their disk just as much as 
> people wanting to edit the website need the kernel source.  Having them 
> separate allows these two distinct groups to not need to check out reams 
> of data they don't actually need.

I'm not sure you quite understand how svn works. :)  You can easily
check out portions of the repo, and as someone else pointed out already
that's the common model of working with it. You can even check out
"sparse" trees at any level. For instance I have all of head and
stable/8 locally, but I only check out bits of stable/7 when I want to
MFC something; and I have vendor/bind9 only, etc. The procedure for
doing this takes a few minutes to learn, but once you have your partial
tree checked out it's easy to add/update things in it.


hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/