[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SVN layout

On Tue, 2005-08-30 at 15:33 +0200, Sven Luther wrote:
> On Tue, Aug 30, 2005 at 05:41:34PM +0900, Horms wrote:
> > On Fri, Aug 26, 2005 at 05:53:38PM -0400, Andres Salomon wrote:
> > > On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote:
> > > [...]
> > > > > >                               svk may be different, if so,
> > > > > > this is a excellent time to discuss that.
> > > > > 
> > > > > It just gets crazy if it can't find merge points.
> > > > 
> > > > Could you elaborate a little. I think you are the only one using
> > > > svk at this point. So perhaps you are seeing problems that aren't
> > > > apparent when svn is used.
> > > > 
> > > > When you say merge point? Does svk dictate that your head is
> > > > in trunk/ and directories in branch/ are siblings of it?
> > > > Or is it just a matter of knowing where each tree is in
> > > > the overall hierachy.
> > > > 
> > > 
> > > If we're going to start catering towards people using the kernel
> > > repository with distribution revision control tools, why not just
> > > use a proper distributed revision control system?  I'm quite tired
> > > of dealing w/ SVN; I consider all these discussions about branches,
> > > naming, etc to be a complete waste of time brought about by SVN's
> > > utterly stupid (lack of) branching and naming policy.  When doing
> > > offline development, I've tended to work using bazaar; online
> > > development usually consists of me flooding #debian-kernel with minor
> > > little commits, as well as dealing w/ conflicts as people write
> > > changelog entries at the same time I do.  It feels a whole lot like
> > > SVN wastes a lot more time than it saves.
> > > 
> > > I can deal w/ SVN for the immediate future, but if people start using
> > > svk anyways, I suggest we simply switch to something like git(/cogito)
> > > or bzr.
> > 
> > Bastian seems to have gone ahead and rearanged SVN to his own liking,
> > so I'll close the book on trying to discuss that out on this list. 
> > 
> > I like your idea of using bzr, for starters, it has
> > branching and merging. For seconds, people can do
> > this however they please, so we don't need these tedious 
> > debates. And there are all sorts of other good things,
> > like with ubuntu, which might well make things like 
> > security patches less of a burden.
> > 
> > Questions
> > 
> > 1. How, if at all, do you interface baz/bzr with svn.
> >    Is it just a manual process?

What do you mean, "interface"?  Do you mean converting the repository?
If there's not already svn2bzr and svn2git tools, I can't imagine they'd
be that difficult to create (there's already various other tools to
convert between the various free RCS's).  Or do you mean keeping the
main repository in svn while working locally w/ baz/bzr?  For me, it's
been a manual process; I've only recently started using bzr, my offline
debian-kernel stuff has been done using baz.

> > 
> > 2. Who doesn't want to use baz/bzr instead of svn.

Well, to clarify; I wouldn't want to use baz.  It's inflexible and
difficult to use (thanks to its tla ancestry).  However, bzr would
certainly make a fine choice, and it's pretty simple to use.

> Just a quick question, as i am not familiar with either revision control
> system, but wouldn't it make more sense to use git, seeing as the kernel is
> using it, and we could then even handle our own whole kernel tree in it,
> tracking upstream or whatever. Not sure about the difference between them

I don't think it would make too much of a difference; both have pros and
cons.  However, both are also under heavy development; so, their
downsides are quickly becoming less and less.  I don't think upstream's
choice should really affect ours.  My main concern w/ using either of
them is their source format changing, breaking things; for example, I
maintain gitweb, and have had problems w/ newer versions of git/cogito
entering sid that completely break gitweb.

> though, and if this makes sense or not, but as far as learning
> yet-another-versioning-system, i guess it is easier to learn the one used by
> upstream kernel developers.

The learning curve for both is pretty minimal.

> And is baz/bzr different or mostly the same as uncomprehensible arch/tla ?

baz is pretty incomprehensible.  bzr is not; it's about as easy to use,
if not easier, than svn.  cogito is pretty easy to use as well; however,
the command line usage takes a bit of getting used to (instead of
"{cvs,svn,bzr} <command>", commands are in the form "cg-<command>" for
example).  I use both regularly; my worst problem with them tends to be
running bzr commands in a git repository, or vice versa.  :)

Reply to: