Conversion to SVN

[Doug Barton]

On 10/09/2011 04:59, Gavin Atkinson wrote:
> 
> 
> On Fri, 7 Oct 2011, Doug Barton wrote:
> 
>> 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 don't like the idea that r226166 can be a change from 10 minutes ago, 
> and r226167 would be a change from 1994.

Well that couldn't happen because the numbers increase monotonically
over the whole repo, but even assuming that you meant the reverse I
still don't understand why you care what the number is.

Let's assume that we start a new repo for doc. What's going to happen is
that the cvs -> svn converter will take the first set of files added to
the repo and they will be revision 1. Then the next set will be revision
2, etc. What's incredibly likely to happen is that for any given file
your new change is going to be revision NNN and the immediately-previous
change is going to be revision XXX, where the values could be just about
anything, say NNN=659 and XXX=237. So what does it matter if the numbers
are 2 or 3 or 4 digit "random" numbers, or if the numbers are 6 digits?

When I first started working with svn for src/ I was taken aback by
this, but once you get used to it you realize that it really isn't a
problem.

>>> 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.
> 
> Given that moving directories is a cheap process in SVN, I'm tending 
> towards feeling that rearranging the repo can be done after the 
> conversion, and not necessarily during.

I sort of agree, but I think giving some thought to it now will save a
lot of headache later. Certainly we shouldn't be thinking of doing the
conversion prior to 9.0-RELEASE, so we have a couple months at least.

>>> 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.
> 
> Indeed, but we still maintain a nominal distinction between src, doc and 
> ports committers, meaning that when somebody commits to a different 
> repository this gets flagged in the commit message.  I'm working on the 
> assumption that the distinction between different commit bits will remain.

So am I.


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/