Re: in -current is svn still canonical?

from Warner Losh and my last message:

> > Thanks for the information, but if you feel the need to send me a
> > not-quite-CC, please don't send me the multipart/alternative version when
> > you send the plain-text version to the list.

> > I hate multipart/alternative!
        
> I must apologize. Sadly, I use gmail, so I have no control over how it
> decides to encode things, sadly. I've tried in the past, and alas, nothing
> I've tried works for any length of time. Please forgive me whatever
> unspeakable MIME atrocities it sends on my behalf. I've removed you from
> the cc line in the hopes that the FreeBSD mail server cleans things up to  
> be more to your liking.
        
The message on the list had only the plain-text part.  Either you sent it differently, or the list server stripped the HTML attachment.
        
> > When git becomes the source of truth on FreeBSD after the flag day, will
> > it be necessary to git-clone the whole tree from scratch, or will there be
> > a conversion tool to switch the svn download to proper git format?
       
        
> For the supported stable branches, you'll be able to download via
> subversion and switch over at any time before the end of project support
> for the branch.

I suppose this applies only to the current stable branches (11 and 12) but not to future stable branches, beginning with 13?
        
> However, when you make the switch to git (either due to the flag day and
> tracking -current, or jumping from svn on a stable branch), there's no tool
> to convert the subversion checked out tree to a git tree. The needed
> information needed to create the git tree isn't easily available from the
> subversion checkout, so you'll need to do a git clone. If bandwidth is a
> problem, you can do a shallow clone that omits all the history and just
> grabs the branch of interest. Git is a bit more link efficient than
> subversion, which is helpful. Git also has ways to help you share one local
> repo across checked out versions, which can also help if you have to track
> multiple branches.

I suppose I would then git-clone the current/13 src tree separately and delete the svn version.
        
> > The doc tree is much smaller than the src tree, while the ports tree is
> > much bigger than the src tree.  Is that the reason for the few-months-long
> > lag switching the ports trree to git?
 
        
> There's a couple of things that make it trickier. The ports tree does
> quarterly branches. So there's a window around the quarterly branch when
> it's easiest to make the switch. In addition, the character of the files in  
> the ports tree differs from src. Unlike subversion, git infers copies,
> moves, etc. The mostly similar nature of the ports tree is likely to cause
> git grief when ports are copied, resurrected from the attic, etc. The ports
> folks are still figuring out how to best use git to track the history they
> need to track without creating undue issues. It's not clear if that will
> all be sorted out before the next window in December, or if they will have
> to defer until March. This is why I hedged a bit as to the exact time,
> since it's not been nailed down yet. So it's not so much the size, as the
> difference in makeup and character between the two trees. The doc tree is,
> as you point out, much smaller, less active and its needs are more modest
> and largely mirror the src tree, so it can be done quickly at any time.

> Warner

Now I see the reason for timing the switch of the ports tree from svn to git.

I never tracked the quarterly ports tree, just as I never followed the quarterly (NetBSD) pkgsrc, only the current version.        

NetBSD is readying to switch src trees and pkgsrc from cvs to hg (Mercurial), but it takes some time to prepare and not mess things up.

I am under the impression that they intend to switch everything over at once when ready.

Pkgsrc has both current and quarterly, so maybe they will have issues similar to FreeBSD ports on switching to hg.

I have git installed on both FreeBSD and NetBSD, but no Mercurial.

As far as I can see, git repositories greatly outnumber mercurial repositories.

Tom