http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/312 Stefano Zacchiroli 2008-12-02T13:38:58 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/311 Well, it's http access logs as well, but that would be an interesting thing to do. I'm not sure whether providing branches for each VCS is a good idea, as I'm not sure it would help collaboration that much. If I grab a bzr branch to work on a feature, and you want to use git to work on that feature too then we have to provide a service to synchronise branches for you, and you would have to wait while my branch was imported to git before you could start work. I'm not saying that you shouldn't be allowed to work in your preferred VCS, just that trying to provide branches of everything in every VCS isn't going to be a workable solution in my opinion. I think investing time in things like git-bzr and allowing you to get git branches of the things you are interested in would be a better way to go. The whole Debian archive. The branches we have are not just for main they are all ~15000 source packages. Thanks for the information, it sounds like we might be a bit stuck there. Sorry about that, I didn't James Westby 2008-12-01T17:09:58 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/310 martin f krafft 2008-12-01T10:46:53 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/309 Stefano Zacchiroli 2008-12-01T08:15:47 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/308 Pierre Habouzit 2008-12-01T09:24:44 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/307 Robert Collins 2008-11-30T21:08:48 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/306 I'm not sure what you mean here, could you clarify? The logic is in bzr-builddeb. There are some scripts that run that in a loop after checking what versions of a package haven't been imported after grabbing that information to launchpad which are not in the branch. http://code.launchpad.net/bzr-builddeb It's pretty tied to bzr currently, but the ideas don't require bzr. You could implement different back-ends, but I don't have a desire to, and I'm not sure it would be a good idea. Yeah, for things maintained in VCS we plan to suck the packaging directly in to bzr and use that, we've just focused on the general case first. There are some difficulties though. For instance we want full source branches, and a lot of SVN packaging is mergeWithUpstream style, so we will have to put it back together again while still making it useful for collaboration. We also need to handle the probably hundreds of tagging schemes out there to be able to tag the historic releases appropriately. (We tag every releas James Westby 2008-11-30T21:06:05 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/305 Stefano Zacchiroli 2008-11-30T18:23:52 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/304 Stefano Zacchiroli 2008-11-30T18:32:50 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/303 Hi, Paul suggested that I explain a little bit about how I see this affecting vcs-pkg. In my opinion it doesn't prejudice the aims of vcs-pkg at all. All we are doing in essence is representing existing source packages in bzr. We haven't settled on a set of tools to manage the branches, or a workflow to interact with upstream etc. In fact, as they don't share revision history with any upstream branches that's not really feasible right now. In fact I think this will benefit vcs-pkg quite a bit. Firstly, with lots more people using VCS for packaging we will learn more about the requirements. We will also see some new tools and approaches springing up. It will also provide us with a testbed where we can experiment with things on a larger scale. In a way it has started a clock ticking, in that as this moves forward we will need good answers to a lot of the questions that vcs-pkg is asking, and if vcs-pkg doesn't provide them then other solutions will spring up. It's not going to be rapid progress though, James Westby 2008-11-28T16:10:35 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/302 James Westby 2008-11-27T09:28:26 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/301 martin f krafft 2008-11-26T09:24:25 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/300 martin f krafft 2008-11-25T10:05:44 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/299 martin f krafft 2008-11-25T08:51:42 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/298 martin f krafft 2008-11-23T13:25:14 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/297 * Sam Liddicott [Mon, 24 Nov 2008 14:52:22 -0000]: It's a plugin but it's not enabled by default, the wiki admin needs to do so. Adeodato Simó 2008-11-24T15:04:46 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/296 Sam Liddicott 2008-11-24T14:55:43 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/295 Sam Liddicott 2008-11-24T14:52:22 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/294 Sam Liddicott 2008-11-24T14:49:53 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/293 I'm referring to this: All I was pointing out was that the method with which you produce the merged tree doesn't have to correspond to how it is recorded in the history. It's not that complicated, really. I'm referring to the problem you describe in slide 5.1. In a sense, you throw away the merge commits before applying the new change, but keep the tree. So, you end up with a single merge commit for each topic branch without having to rebase all the time, reducing the (subjectively described) "clutter". You're doing some things vaguely like this in your slide 5.3, if a little haphazardly. I'm sorry if these terms make little sense, if they don't I suggest chapter 7 of the Git User Manual that describes the object database. It's a good half hour investment of learning that will make working with git feel much less mystifying. It probably makes sense to make sure that TopGit can deal with the use cases you describe; it possibly is most of the way there already... Martin? Sam. Sam Vilain 2008-11-24T00:05:52 http://permalink.gmane.org/gmane.comp.package-management.vcs-pkg/292 I have no idea what you just said; so I couldn't possibly have been participating in a discussion about that. This seems a worse cure than the illness, in that it is so complicated I am not sure I understand it either. What intermediate merge commits? My current workflow is somewhat like §5.4 on the page: http://www.golden-gryphon.com/software/misc/packaging.html except that I never to the rebase bit until I am ready to submit the patch upstream. Does that explain the use case? manoj Manoj Srivastava 2008-11-23T05:19:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.package-management.vcs-pkg