Conversion to SVN

Benedict Reuschling bcr at FreeBSD.org
Thu Nov 3 21:47:51 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 02.11.11 22:26, schrieb Spörlein:
> On Wed, 2011-11-02 at 12:36:31 -0700, Doug Barton wrote:
>> On 11/02/2011 11:21, John Baldwin wrote:
>>> If you really want to do this in the same repo, I won't object. 
>>
>> Just to be clear, I personally do think it's the right design choice,
>> sure. But there are also plenty of people who have been talking about
>> the benefits that this would bring. It would be nice if some of those
>> people speak up now. :)
> 
> 1. One less thing to admin/maintain (and btw, I'm of the opinion we
> should get rid of the svn->cvs exporter, but that's another can of
> worms)
> 
> 2. Changesets spanning source *and* documentation.
> 
> 3. The possibility to svn mv parts of src into doc and vice versa. Might
> actually simplify release building, but I'm not familiar with that.
> 
> 4. Less confusion about what a svn revision number means. With CVS IDs
> everybody knew it's about a file. If we would have two or three SVN
> repos, then 'r123456' can mean three wildly different things.
>
Indeed, but we agreed (more or less) that we should put ports into a
separate repo (once they do the actual conversion). So even if we agreed
on putting doc and src together into one repo, there will still be
ambiguity about which revision number has been referred to: the doc+src
one or the one in the ports repo, right. ;)

Speaking of the ports repo: I remember (correct me if I'm wrong) that a
portion of the ports repository (or certain ports within it) is required
to build the handbook, so there is already a more or less tightly knit
connection between the doc and the ports repo. If we want to make things
better (which we should), then we might want to take this fact into account.

> 5. There's already more than just source in the svn, namely portmaster
> and stress2. It would be nice if we could move all the "user" stuff from
> /projects into /user and have /projects be for non-source stuff like
> stress2 and portmaster.
> 
> And while we're at it, we call it 'docproj', so why not stick it under
> /projects/doc ? (I'm only partially serious about this ...)
> 
> I'm sure there's more that will only be obvious once we've done the
> switch. But the actual doc committers have been very silent on this
> subject lately.
> 

Well, I for one (welcome our new SVN overlords) have been watching the
discussion that unfolded with a keen interest. It seems that there are
as much arguments for/against a combined doc+src repo as well as for
keeping them separate (and vice versa). From my point of view, I could
live with both. However, I remember one thing from my (otherwise very
boring) distributed systems lecture back when I was a student: If you
are not sure whether to distribute or not, then it is better to
distribute, rather than figuring it out afterwards, because it then
becomes more messy to divide things again. Something like that, I don't
know if that is of any help here (but this would mean separate repos then).

I just want to have the SVN migration get underway sooner than later,
given all the time it requires to make the transition, of course.
Cutting off CVS (no svn2cvs export required IMO) and get back to work,
since the next big thing(tm) would be the switch to DocBook XML, which
we agreed at the EuroBSDcon DevSummit doc session should come afterwards.

Doceng wanted to work on this issue further, but I guess they are busy
with release work.

Has anyone else some ideas to contribute?

Regards

Benedict Reuschling
FreeBSD Documentation Committer

The FreeBSD Documentation Project
FreeBSD German Documentation Project - https://doc.bsdgroup.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6zCXoACgkQTSZQLkqBk0jHnACeP01eLdTSzYmhLvWuTQ3kryXG
SJQAn3tX+4bh4qoiZYou/9Da7vYlQMCy
=+mCE
-----END PGP SIGNATURE-----



More information about the freebsd-doc mailing list