Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-08-02 Thread Grant Defayette

On Sat, 2007-07-28 at 17:28 +0200, Sebastien Bacher wrote:
 Hi,
 
 We are looking at maintaining the ubuntu-desktop packages in bzr. The
 idea is to store the debian directories there and to use
 bzr-buildpackage and some other tools making the work easier.
 
 There is a question though, which is to know if we should better use one
 branch by package or one for everything. I'm trying to summarize some
 advantages and inconveniences of each method:
 
 * One branch by package:
 + that's the clean way using bzr
 + you can checkout and look at updates for the packages you are
 interested in only
 - you need to checkout or update ~100 different branches when you work
 on all the packages
 - you need to branch for every package when gutsy+1 opens
 
 * One branch for all the packages:
 + you only need one command to branch, get or update the team packaging
 sources
 + easier to look if something changed
 - you need to checkout the debian directories for all the packages
 (quite small)
 
 The team contributors are likely to work on different packages and I
 think it would be easier to have everything at the same location.
 
 Daniel has written a get-branches tool to make easy to get or update
 all the branches from a team, it has to connect and do checkout for
 every package though which is quite slow and quite verbose.
 
 
 What do you think? What method would you like better? Extra arguments
 and thoughs are welcome!
 
 
 Thanks,
 
 Sebastien Bacher
 
 
 
How about dividing the branches into categories with packages split into
different subdirs. Many closely related packages are all changed at the
same time and therefore should not be in different branches. To combine
them all in one branch sounds like a good idea, but maintaining it might
be a nightmare. To track all changes made to such an all encompassing
branch would be very difficult.
Off to-pic a bit, as far as I know bzr does not allow sub branches with
different access rules, could be useful.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-31 Thread Michael Vogt
On Sat, Jul 28, 2007 at 05:28:35PM +0200, Sebastien Bacher wrote:
 Hi,
Hi,
 
 We are looking at maintaining the ubuntu-desktop packages in bzr. The
 idea is to store the debian directories there and to use
 bzr-buildpackage and some other tools making the work easier.

Hoorah!
 
[..]
 * One branch by package:
 + that's the clean way using bzr
 + you can checkout and look at updates for the packages you are
 interested in only
 - you need to checkout or update ~100 different branches when you work
 on all the packages
 - you need to branch for every package when gutsy+1 opens
[..]

I like this approach much better. One disadvantage here is that
launchpad requires a upstream product for each branch but there is no
mapping for every current source packages to a upstream products. So
some will have to be created first with the webgui in LP. Better
support from LP would be helpful here I think (either auto creating
upstream product or allowing bzr branches for source package names).

Cheers,
 Michael

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-30 Thread Loïc Minier
On Mon, Jul 30, 2007, Robert Collins wrote:
   The current implementation is very simple (for branch in iter():
   pull()), but there are at least two solutions to help with speed:
   1) (already proposed) rewrite this to reuse a transport when possible
 This is the right approach.

 Okay, I gave it a shot (see attached patch), all will propose this for
 inclusion in bzrtools; I filed this under Debian's bzrtools package for
 now. [1]

 Not sure whether the old behavior should still be made available.


[1] following the advice at https://bugs.launchpad.net/bzrtools/+filebug
-- 
Loïc Minier
--- bzrtools-0.18.0/debian/changelog
+++ bzrtools-0.18.0/debian/changelog
@@ -1,3 +1,11 @@
+bzrtools (0.18.0-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Group branches by URL base and reuse one transport per URL base to avoid
+reopening a connection for each pull in multi-pull.
+
+ -- Loic Minier [EMAIL PROTECTED]  Mon, 30 Jul 2007 12:06:43 +0200
+
 bzrtools (0.18.0-1) unstable; urgency=low
 
   [ Arnaud Fontaine ]
--- bzrtools-0.18.0.orig/__init__.py
+++ bzrtools-0.18.0/__init__.py
@@ -503,27 +503,72 @@
 if not t.listable():
 print Can't list this type of location.
 return 3
-for branch, wt in iter_branch_tree(t):
-if wt is None:
-pullable = branch
-else:
-pullable = wt
-parent = branch.get_parent()
-if parent is None:
-continue
-if wt is not None:
-base = wt.basedir
-else:
-base = branch.base
-if base.startswith(t.base):
-relpath = base[len(t.base):].rstrip('/')
-else:
-relpath = base
-print Pulling %s from %s % (relpath, parent)
-try:
-pullable.pull(Branch.open(parent))
-except Exception, e:
-print e
+print Grouping branches by URL
+by_urlbase = pullable_infos_by_urlbase(t)
+for urlbase in by_urlbase:
+print Processing branches for %s/ % urlbase
+urlbase_transport = get_transport(urlbase)
+for pi in by_urlbase[urlbase]:
+pullable = pi.get_pullable()
+relpath = get_relpath(t.base, pi.get_base())
+parent = pi.get_parent()
+from bzrtools import bzrdir_from_transport
+pull_transport = urlbase_transport.clone(get_relpath(urlbase, parent))
+bzrdir = bzrdir_from_transport(pull_transport)
+pull_branch = bzrdir.open_branch()
+print Pulling %s from %s % (relpath, parent)
+try:
+pullable.pull(pull_branch)
+except Exception, e:
+print e
+
+
+def get_relpath(base, path):
+if path.startswith(base):
+return path[len(base):].rstrip('/')
+else:
+return path
+
+
+class PullableInfo:
+def __init__(self, branch, wt):
+self.branch = branch
+self.wt = wt
+
+def get_pullable(self):
+if self.wt is None:
+return self.branch
+return self.wt
+
+def get_parent(self):
+return self.branch.get_parent()
+
+def get_base(self):
+if self.wt is not None:
+return self.wt.basedir
+return self.branch.base
+
+def get_urlbase(self):
+import re
+# always matches at least the empty string
+urlbase_pattern = re.compile(^(([^:]*://)?([^/]*)))
+return urlbase_pattern.match(self.get_parent()).groups()[0]
+
+
+def pullable_infos_by_urlbase(t):
+pullables_by_urlbase = {}
+from bzrtools import iter_branch_tree
+for branch, wt in iter_branch_tree(t):
+parent = branch.get_parent()
+if parent is None:
+continue
+pullable_info = PullableInfo(branch, wt)
+urlbase = pullable_info.get_urlbase()
+try:
+pullables_by_urlbase[urlbase] += (pullable_info, )
+except KeyError:
+pullables_by_urlbase[urlbase] = (pullable_info, )
+return pullables_by_urlbase
 
 
 class cmd_branch_mark(bzrlib.commands.Command):
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-29 Thread Sebastien Bacher

Le dimanche 29 juillet 2007 à 01:52 +0200, Loïc Minier a écrit :

  Daniel has written a get-branches tool to make easy to get or update
  all the branches from a team, it has to connect and do checkout for
  every package though which is quite slow and quite verbose.
 
  Cool, I did a similar one for hildon; I hope we can share code.

Daniel's code is in bzr,
https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk


Sebastien Bacher



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-29 Thread Loïc Minier
On Sun, Jul 29, 2007, Sebastien Bacher wrote:
 Daniel's code is in bzr,
 https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk

 Mine is at:
https://code.launchpad.net/python-launchpad-code

 I just imported the script I've been using to sync Ubuntu branches on
 alioth.  There's Debian packaging too.  Advantages:
 - the code parsing code.launchpad.net pages is isolated in a Python
   module
 - written in BeautifulSoup instead of re
 - you're not forced to pull all branches (you are supposed to use a map
   file saying which branches you want)
 - you can use the same script to pull branches from various teams /
   persons (-p lool -p ubuntu-mobile), but I didn't test this

-- 
Loïc Minier

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-28 Thread Sebastien Bacher
Hi,

We are looking at maintaining the ubuntu-desktop packages in bzr. The
idea is to store the debian directories there and to use
bzr-buildpackage and some other tools making the work easier.

There is a question though, which is to know if we should better use one
branch by package or one for everything. I'm trying to summarize some
advantages and inconveniences of each method:

* One branch by package:
+ that's the clean way using bzr
+ you can checkout and look at updates for the packages you are
interested in only
- you need to checkout or update ~100 different branches when you work
on all the packages
- you need to branch for every package when gutsy+1 opens

* One branch for all the packages:
+ you only need one command to branch, get or update the team packaging
sources
+ easier to look if something changed
- you need to checkout the debian directories for all the packages
(quite small)

The team contributors are likely to work on different packages and I
think it would be easier to have everything at the same location.

Daniel has written a get-branches tool to make easy to get or update
all the branches from a team, it has to connect and do checkout for
every package though which is quite slow and quite verbose.


What do you think? What method would you like better? Extra arguments
and thoughs are welcome!


Thanks,

Sebastien Bacher



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-28 Thread Loïc Minier
On Sat, Jul 28, 2007, Sebastien Bacher wrote:
 We are looking at maintaining the ubuntu-desktop packages in bzr. The
 idea is to store the debian directories there and to use
 bzr-buildpackage and some other tools making the work easier.

 Huzzah!  \o/

 * One branch by package:

 I think that's the sane way of doing things.  I would take the same
 choice with e.g. git, and I think this is natural.  It maps very well
 with upstream having one SVN repo per package too, and I think we have
 been wrong in using complex layouts in the SVN repositories in alioth.

 - you need to checkout or update ~100 different branches when you work
 on all the packages

 Yeah; I wrote my own script to do this, but then realized there's
 already a multi-pull command in bzrtools.  But I agree with other
 posters that this needs to be fixed, it shouldn't be a blocker.

 The current implementation is very simple (for branch in iter():
 pull()), but there are at least two solutions to help with speed:
 1) (already proposed) rewrite this to reuse a transport when possible
 2) add a connection cache / pool to bzr which would permit reusing a
transport during a small period of time

 - you need to branch for every package when gutsy+1 opens

 I'm not sure this is strictly required: I could imagine using one
 ubuntu branch (and one debian branch obviously :) as the main
 Ubuntu trunk which would basically map to upstream's trunk, or
 whatever you're currently tracking for $next_release.
   Perhaps it's not strictly needed to have branches for each release
 and the backports can be done manually, directly from the archive as
 right now?  Or perhaps the branches should be created ad hoc, for
 example a new branch ubuntu-gutsy-backports would be initiated only
 when a backport is needed?

 Daniel has written a get-branches tool to make easy to get or update
 all the branches from a team, it has to connect and do checkout for
 every package though which is quite slow and quite verbose.

 Cool, I did a similar one for hildon; I hope we can share code.

-- 
Loïc Minier

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop