Re: svn layout confusion
On Tue, Sep 06, 2005 at 10:06:45AM -0400, Andres Salomon wrote: On Tue, 2005-09-06 at 15:20 +0200, Sven Luther wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What Indeed. about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix uploads to etch by t-p-u (if this is not still broken). I wouldn't really consider 2.6.12 to be etch release-material until the packaging changes settle down; more of something for d-i and etch users to use while we finalize the packaging. I wouldn't want to see etch actually release w/ -6. Agreed, though currently Etch is testing, and the likelyhood that Etch is magically released as stable before we have a chance to make another release, and indeed settle down the packaging, seems remote. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
svn layout confusion
Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What Indeed. about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix uploads to etch by t-p-u (if this is not still broken). So, the natural thing to do then, is to svn mv dists/sid to /dists/etch at that time, and svn cp dists/trunk as dists/sid. Then we make 2.6.13 releases in dists/sid, while 2.6.12 is slowly phased out, and make brand-new-out-of-git 2.6.14-rc or whatever uploads to experimental from dists/trunk. That said, i believe that the single linux-2.6 thingy is maybe not the best idea after all, but maybe we can, if t-p-u is still broken, as it seems to be as far as i remember, do linux-2.6.12 uploads out of dists/etch, in parallel to linux-2.6 uploads (which will be 2.6.13) out of dists/sid. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, 2005-09-06 at 22:25 +0900, Horms wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? I think this is pretty confusing myself, though I believe that the idea is that if sid and trunk are the same, then you nuke the sid branch. So basically things only exist in sid/ if we are working on something newer than what is in sid (and being maintained). Pretty much what I was thinking; why keep a branch around when we're not using it? Why not just create trunk only when it's different from sid (or vice versa, whatever the svn users like to call HEAD). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, 2005-09-06 at 15:20 +0200, Sven Luther wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What Indeed. about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix uploads to etch by t-p-u (if this is not still broken). I wouldn't really consider 2.6.12 to be etch release-material until the packaging changes settle down; more of something for d-i and etch users to use while we finalize the packaging. I wouldn't want to see etch actually release w/ -6. But yes, your explanation makes sense for 2.6.13 (assuming we want to release with it). Also, we'll probably be doing uploads to testing-security more often than t-p-u. So, the natural thing to do then, is to svn mv dists/sid to /dists/etch at that time, and svn cp dists/trunk as dists/sid. cp or mv? If we only cp, dists/trunk gets stale as we work on dists/sid, and would need to be manually synched. Then we make 2.6.13 releases in dists/sid, while 2.6.12 is slowly phased out, and make brand-new-out-of-git 2.6.14-rc or whatever uploads to experimental from dists/trunk. How often do we intend to do those? I don't like the idea of two possible development trees getting out of synch; if dists/sid only contains patch updates, that's fine. However, if dists/sid contains packaging updates (ie, fixes to gencontrol.py and such), then keeping dists/trunk in synch with that will become troublesome.. It sounds to me like dists/trunk should be a branch of dists/sid, created whenever there's experimental packaging or patch work being done. That said, i believe that the single linux-2.6 thingy is maybe not the best idea after all, but maybe we can, if t-p-u is still broken, as it seems to be as far as i remember, do linux-2.6.12 uploads out of dists/etch, in parallel to linux-2.6 uploads (which will be 2.6.13) out of dists/sid. Yea, the dists/etch thing makes sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn layout confusion
On Tue, Sep 06, 2005 at 10:06:45AM -0400, Andres Salomon wrote: On Tue, 2005-09-06 at 15:20 +0200, Sven Luther wrote: On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote: Ok, so now that we have dists/sid and dists/trunk (which is for development and experimental stuff); how is this actually supposed to work? I understand the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick any new development stuff in trunk, backport to sid if desired, do sid releases from dists/sid, and experimental releases from dists/trunk. What Indeed. about the case where we have 2.6.13 in both? Are we supposed to do all releases from trunk, and branch/cp to sid? Are we supposed to do releases from sid, and keep trunk ready for 2.6.14 development; regularly forward-porting changelogs and stuff? The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix uploads to etch by t-p-u (if this is not still broken). I wouldn't really consider 2.6.12 to be etch release-material until the packaging changes settle down; more of something for d-i and etch users to use while we finalize the packaging. I wouldn't want to see etch actually release w/ -6. We don't care, 2.6.11 has to go, and 2.6.12 has to move to etch, this does not mean that we will release it as is, but that this is what we want to release when etch is ready. While 2.6.12 is not in etch, this means that all etch d-i installs are broken, and 2.6.8 or whatever cannot go. But yes, your explanation makes sense for 2.6.13 (assuming we want to release with it). Also, we'll probably be doing uploads to testing-security more often than t-p-u. Hehe. So, the natural thing to do then, is to svn mv dists/sid to /dists/etch at that time, and svn cp dists/trunk as dists/sid. cp or mv? If we only cp, dists/trunk gets stale as we work on dists/sid, and would need to be manually synched. My idea was that at a given time trunk would be the 2.6.13 release candidate, and once we start uploading it to sid, then this one becomes the main work for sid, and trunk is forked from there for future follow-2.6.14-rc-whatever development, once 2.6.14 is released, hopefulyl 2.6.13 will have made it to testing, and we can then do the above dance once more. Then we make 2.6.13 releases in dists/sid, while 2.6.12 is slowly phased out, and make brand-new-out-of-git 2.6.14-rc or whatever uploads to experimental from dists/trunk. How often do we intend to do those? I don't like the idea of two possible development trees getting out of synch; if dists/sid only contains patch updates, that's fine. However, if dists/sid contains packaging updates (ie, fixes to gencontrol.py and such), then keeping dists/trunk in synch with that will become troublesome.. That is indeed a problem. We could manage the packaging fixes in a single repo, and link to there from it, not sure if this is possible wih svn though. Or maybe even copy it from there when building ? The patches and configs are essentially what will need to be forked for the different tree, and i guess that there is no chance for it to work for all three dists anyway. It sounds to me like dists/trunk should be a branch of dists/sid, created whenever there's experimental packaging or patch work being done. Indeed. That said, i believe that the single linux-2.6 thingy is maybe not the best idea after all, but maybe we can, if t-p-u is still broken, as it seems to be as far as i remember, do linux-2.6.12 uploads out of dists/etch, in parallel to linux-2.6 uploads (which will be 2.6.13) out of dists/sid. Yea, the dists/etch thing makes sense. Cool, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 11:10:19PM +0200, Bastian Blank wrote: No reply? Bastian -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, By Any Other Name, stardate 4657.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Fri, Sep 02, 2005 at 07:09:36PM +0200, Bastian Blank wrote: On Wed, Aug 31, 2005 at 11:10:19PM +0200, Bastian Blank wrote: No reply? Bastian Was there something to reply ? I didn't get the impression that you gave any valuable reason, and read again is not something which i understand as is. I prefer to abstain from commenting until i get more clear explanations, and i guess this is similar for others. Notice though, that apart from you, all those that participated in this thread where in favour for that move. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Final decision, please vote ... Re: SVN layout
On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: Hi, with the advent of the unified kernel package for 2.6 some of the original SVN layout has become irrelevant. As a background here is how things used to look. Ok, this mess can no longer continue, since it is paralizing us all, and i am going to make now a proposal, which should satisfy each side, i believe. Currently most important stuff is under branches/dist, and i think it would be best to make this dist to the toplevel, and kill the superficial branch part. So, we would have : dists dists/sarge dists/sarge-security dists/sid dists/experimental or dist/trunk And we move stuff there. We then can add a : dists/common For stuff common to all distributions, like the utils and so on, but which can live also under the the individual distribs if we need them. Waldi, i would like your express comment on this, but i believe from your previous comments that this should suite you. All others, i would like your explicit vote on this, so we can reach concensus officially and finally start working again. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 10:43:24AM +0200, Sven Luther wrote: On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: Hi, with the advent of the unified kernel package for 2.6 some of the original SVN layout has become irrelevant. As a background here is how things used to look. Ok, this mess can no longer continue, since it is paralizing us all, and i am going to make now a proposal, which should satisfy each side, i believe. Currently most important stuff is under branches/dist, and i think it would be best to make this dist to the toplevel, and kill the superficial branch part. So, we would have : dists dists/sarge dists/sarge-security dists/sid dists/experimental or dist/trunk And we move stuff there. We then can add a : dists/common For stuff common to all distributions, like the utils and so on, but which can live also under the the individual distribs if we need them. Waldi, i would like your express comment on this, but i believe from your previous comments that this should suite you. All others, i would like your explicit vote on this, so we can reach concensus officially and finally start working again. I am comfortable with this layout. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 12:06:15PM +0200, Bastian Blank wrote: On Wed, Aug 31, 2005 at 10:43:24AM +0200, Sven Luther wrote: We then can add a : dists/common For stuff common to all distributions, like the utils and so on, but which can live also under the the individual distribs if we need them. We don't have anything really common. The versions between stable and unstable (if applicable) will differ anyway. Well, it can be empty, it was just to have a place to put stuff there in case we needed it, it could as well go into dists/trunk though. Waldi, i would like your express comment on this, but i believe from your previous comments that this should suite you. dists/trunk looks a little bit odd but I won't argue against. Thanks, we can now go ahead and do the cleanup. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New SVN Layout ...
Hi all, We finally solved our difficulties, and i did the moving around to hopefulyl their definite place for a while at least of the different things. We now have : dists/sarge dists/sarge-security dists/sid dists/trunk dists/common releases people releases is the old tag dir, which we used to copy when we did releases. common is empty for now, the stuff in dists is coming from branches/dists and turnk. Also, it would be nice for everyone involved to cleanup his stuff in dists/trunk/, mostly the stuff in kernel-to-be-deleted-please-cleanup and kernel-2.4, which are not targeted at etch. I removed the remaining powerpc stuff from there for example, and moved the powerpc 2.4 stuff to the sarge branch. Let's all now go back to working in harmony and preparing both the 2.6.12-6 and 2.6.13-1 uploads. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 12:07:02PM +0200, Sven Luther wrote: Thanks, we can now go ahead and do the cleanup. The linux-2.6 move was not part of this dicision. Bastian -- Totally illogical, there was no chance. -- Spock, The Galileo Seven, stardate 2822.3
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 07:11:12PM +0200, Bastian Blank wrote: On Wed, Aug 31, 2005 at 12:07:02PM +0200, Sven Luther wrote: Thanks, we can now go ahead and do the cleanup. The linux-2.6 move was not part of this dicision. Ok, explain me why you want to have it part of the kernel subdir then, if we are going to empty it of any further content ? I really don't get why you are opposing this move, so how can we come to any concensus if you don't explain yourself ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final decision, please vote ... Re: SVN layout
On Wed, Aug 31, 2005 at 07:12:57PM +0200, Sven Luther wrote: Ok, explain me why you want to have it part of the kernel subdir then, if we are going to empty it of any further content ? Why exists arch and utils? Just move anything up. I really don't get why you are opposing this move, so how can we come to any concensus if you don't explain yourself ? Read again. Bastian -- Vulcans do not approve of violence. -- Spock, Journey to Babel, stardate 3842.4
Re: SVN layout
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? 2. Who doesn't want to use baz/bzr instead of svn. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
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? 2. Who doesn't want to use baz/bzr instead of svn. 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 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. And is baz/bzr different or mostly the same as uncomprehensible arch/tla ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Tue, Aug 30, 2005 at 12:15:23PM -0400, Andres Salomon wrote: 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. I was just wondering if you had an automated process to pull changes in from svn and push them back again. 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. I tend to agree, though my experience with them is limited. In any case, I beleive they are compatible. 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. Using git seemst to be a matter of tracking it upstream (using git). It breaks from time to time. But its under heavy development, so I don't mind too much. I think that bzr is a more powerful tool, and frankly using git to suck patches out of upstream is painful. It seems to be very much geared to wards information going into the tree, moving forward, not mining it for patches as is a more typical maintenance task. This is partly because of the object files system that git is built on top of, which doesn't keep particularly strong links between information. Bzr is in much the same boat, but I think that it has more support underneath, and thus should be more adept to suiting a wide range of developer needs. 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
Re: SVN layout
Hello, On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: Personally, in the context of the two questions above, I advocate trunk/linux-2.6 trunk/linux-2.6-experimental I opt for this solution, too. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: SVN layout
On Thu, Aug 25, 2005 at 05:53:41PM +0900, Horms wrote: Depends on what you mean with developed. We saw that it is not possible to get regular testbuilds of the repository version and I broke 3 uploads because of this. If we want to be able to regulary push working versions into testing, we can't just push unchecked changes into this tree. This means that the sid tree can't be the development tree. The packaging is new, so of course there are going to be problems, hopefully that will stabalise over the next few weeks. Thats not only the packaging. In future most of the updates are config and upstream related. Config updates forced by new upstream version or other things needs testing on every architecture until they can reach the package. A linux-2.6 tree that is targeted for sid, where we make cautious changes and a linux-2.6-experimental tree we we work on somethig greener that is targeted for sid in the future, would seem to resolve this problem, So would as putting stuff in branch/ No, it does not. b) Everything must come off trunk. What do you want to say? I would like to say that trunk is a drirectory, and that all directores in svn are created equal. Subversion is a versioned filesystem and it is up to the user to organize it. Bastian -- Beam me up, Scotty, there's no intelligent life down here! signature.asc Description: Digital signature
Re: SVN layout
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. /rant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SVN layout
Hi, with the advent of the unified kernel package for 2.6 some of the original SVN layout has become irrelevant. As a background here is how things used to look. trunk/kernel/source/kernel-source-2.6.8/ .../kernel-source-2.6.10/ .../kernel-source-2.6.11/ .../i386/kernel-image-2.6.8/ .../kernel-image-2.6.11/ .../kernel-image-2.6.10/ .../powerpc/... and so on for all arches .../kernel-2.4/source/kernel-source-2.4.27/ .../kernel-source-2.4.29/ .../i386/kernel-image-2.4.27/ .../kernel-image-2.4.29/ and so on for all arches obsolete/ same structure as trunk, but for things that are no longer used tags/ more or less the same structure as trunk branches/ never really used. Now, skip forward to now, sarge has been released, and we have unified packaging. The obsolete/ directory has been removed (not sure why, but it wasn't much use, and now one seems ot miss it) people/ has been added, but doesn't seem to be used much branches/dist/sarge now 2.6.8, which is now sarge-only (N.B: for the pedantic, its not actually a branch, its the trunk) branches/dist/sarge-security, branch of 2.6.8 (from branches/dist/sarge) and 2.4.27 (from trunk) So far so good. There is definately room for debate on what goes where, but eveyone seems pretty happy. Now enter an ongoing debate on IRC on what is appropriate for trunk. There is some stuff there from the old structure, mainly everything from kernel-2.4 (the 2.4.29 should probably be relocated or deleted, its never going to be used) and 2.6.11 stuff under linux/, which should also be moved or removed. And then there is the problem of what to do with linux-2.6/ When it was initially created it was called kernel-source-2.6.12, and lived under trunk/kernel/source/. Then, as it evolved it was renamed linux-2.6.12, and as it was for all architectures, it was moved to trunk/kernel/ No one really minded that either. But right now there are two problems that need to be resolved so we know where things are supposed to go. 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ But thats a bit of a departure from the old model, and burns holes in some peoples brains. 2. If we assume that we have two versions of linux-2.6, one based on the current upstream (and likely in sid/testing) and one based on some upstream rc releases (and likely in experimental) where should these two directories go. The main two camps seem to be: a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. b) Everything must come off trunk. Only the very leading edge can be in trunk. If the sid version isn't that then it should go under branches, and if that happens to be the version in sid, it should be branches/dists/sid/linux-2.6 (or branches/dists/sid/kernel/linux-2.6, depending on 1) above). Personally, in the context of the two questions above, I advocate trunk/linux-2.6 trunk/linux-2.6-experimental However I am happy with pretty much anything - i symlink into the hierachy anyway. Also, please keep in mind that svn does not attach any special meaning to trunk/, branch/, tags/, or anything else. Its just a common convention. To reiterate - there is notihing in svn that dictages trunk can't contain branches, or even that a directory trunk must exist. svk may be different, if so, this is a excellent time to discuss that. Another, different, idea that has been floating around is to have separeate branches - directories somewhere at the same level, not neccessarily under somthing called trunk/ or branches/ for each release. This is more or less what branches/dists/ is begining to look like. Perhaps we should put that kind of structure under trunk. And rename trunk to something less contentious. Sorry for the long mail. I'm writing this because discussion on IRC is going no where. Please lets discuss and come to conesensus. Please, lets not randomly copy, delete and move linux-2.6, which many of us are working on, without getting some consenus. Lastly, there are currently two copies of linux-2.6, its a by product of the mashed discusion on IRC. Lets put changes into the one in trunk/linux-2.6 and leave the one in trunk/kernel/linux-2.6 alone until we decide what to do. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
But right now there are two problems that need to be resolved so we know where things are supposed to go. 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ But thats a bit of a departure from the old model, and burns holes in some peoples brains. The old layout burned holes in my brain, so I'd surely welcome this ;-) 2. If we assume that we have two versions of linux-2.6, one based on the current upstream (and likely in sid/testing) and one based on some upstream rc releases (and likely in experimental) where should these two directories go. The main two camps seem to be: a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. This is fine with me. Just make sure -experimental is actually branched of linux-2.6 so svns primitive merging has a chance to work. b) Everything must come off trunk. Only the very leading edge can be in trunk. If the sid version isn't that then it should go under branches, and if that happens to be the version in sid, it should be branches/dists/sid/linux-2.6 (or branches/dists/sid/kernel/linux-2.6, depending on 1) above). Personally, in the context of the two questions above, I advocate trunk/linux-2.6 trunk/linux-2.6-experimental aolme too!/aol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
oh, and additional point, could we stop moving things around without a prior discussion on this list in the future? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 09:58:44AM +0200, Christoph Hellwig wrote: oh, and additional point, could we stop moving things around without a prior discussion on this list in the future? I think that would be an excellent idea. Especaially for anything that is in unstable. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 09:56:55AM +0200, Sven Luther wrote: On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: Personally, in the context of the two questions above, I advocate trunk/linux-2.6 trunk/linux-2.6-experimental I vote for this also, and would probably vote for moving the sarge and co branches here too. I am fine with moving sarge and sarge-security. However I am happy with pretty much anything - i symlink into the hierachy anyway. Also, please keep in mind that svn does not attach any special meaning to trunk/, branch/, tags/, or anything else. Its just a common convention. To reiterate - there is notihing in svn that dictages trunk can't contain branches, or even that a directory trunk must exist. svk may be different, if so, this is a excellent time to discuss that. One interesting thing is for people to be able to easily checkout a part of the tree that is actually usefull (well, trunk right now), and not checkout a bunch of stuff which is managed smartly on the svn server side, but spills out to multiple copies on the client side (tags come to mind). So, the proposal to have : trunk, tags and people on the toplevel, and then everything that is actually used goes into trunk. We can rename trunk to main or whatever if it makes people more confortable. I think a good portion of this argument centres around trunk being trunk, so renaming would probably remove any connotations that the name trunk carries. Maybe we could revive the historical or obsolet toplevel for stuff which are going away, like the kernel-soruce-2.6.11 stuff for example, for easier access than going fishing for them in older revisions of the repo. I think there is some value in having histroical/obsolete. I'd welcome its return. So, : main main/sid main/sid/linux-2.6 main/experimental/linux-2.6 main/sarge tags people historical Would be a possible layout. Thats fine by me too. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ linux-nonfree-2.6 and linux-patch-2.6.12-mips are missing from your list and we can move anything directly into trunk with this rationale. a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. Depends on what you mean with developed. We saw that it is not possible to get regular testbuilds of the repository version and I broke 3 uploads because of this. If we want to be able to regulary push working versions into testing, we can't just push unchecked changes into this tree. This means that the sid tree can't be the development tree. b) Everything must come off trunk. What do you want to say? 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. Bastian -- Behind every great man, there is a woman -- urging him on. -- Harry Mudd, I, Mudd, stardate 4513.3 signature.asc Description: Digital signature
Re: SVN layout
On Thu, Aug 25, 2005 at 09:56:55AM +0200, Sven Luther wrote: main main/sid main/sid/linux-2.6 main/experimental/linux-2.6 main/sarge releases people This layout removes the indicator, where changes may be introduced without breaking too much. Bastian -- Humans do claim a great deal for that particular emotion (love). -- Spock, The Lights of Zetar, stardate 5725.6 signature.asc Description: Digital signature
Re: SVN layout
On Thu, Aug 25, 2005 at 10:32:59AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ linux-nonfree-2.6 and linux-patch-2.6.12-mips are missing from your list and we can move anything directly into trunk with this rationale. They could be releases/sid/linux-nonfree-2.6 and releases/sid/arch/mips/linux-patch-2.6.12-mips ? a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. Depends on what you mean with developed. We saw that it is not possible to get regular testbuilds of the repository version and I broke 3 uploads because of this. If we want to be able to regulary push working versions into testing, we can't just push unchecked changes into this tree. This means that the sid tree can't be the development tree. Well, but we still need the sid tree fairly available to make bug fixes and such, but yes, it definitively makes sense to have both a sid and an experimental tree. Maybe we could even do daily-builds out of the experimental tree or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 10:32:59AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 04:49:59PM +0900, Horms wrote: 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ linux-nonfree-2.6 and linux-patch-2.6.12-mips are missing from your list and we can move anything directly into trunk with this rationale. Sorry, I missed them. In my mind, the idea of a deeper structure makes sense if there are a bunch of things that need to be grouped togehter, or if trunk/ gets too messy. If 2.6 is linux-2.6 + linux-patch-2.6.12-mips + linux-nonfree-2.6, then trunk/kernel/ is probably a better place than trunk/ On a slightly tangential note, why do we have linux-patch-2.6.12-mips, when all other archtectues just have linux-2.6? a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. Depends on what you mean with developed. We saw that it is not possible to get regular testbuilds of the repository version and I broke 3 uploads because of this. If we want to be able to regulary push working versions into testing, we can't just push unchecked changes into this tree. This means that the sid tree can't be the development tree. The packaging is new, so of course there are going to be problems, hopefully that will stabalise over the next few weeks. A linux-2.6 tree that is targeted for sid, where we make cautious changes and a linux-2.6-experimental tree we we work on somethig greener that is targeted for sid in the future, would seem to resolve this problem, So would as putting stuff in branch/ Actually, appart from where the directories are, its exactly the same. So we may as well put the directires somewhere that makes peoples lives easier, thus this conversation. b) Everything must come off trunk. What do you want to say? I would like to say that trunk is a drirectory, and that all directores in svn are created equal. 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. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 10:35:11AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 09:56:55AM +0200, Sven Luther wrote: main main/sid main/sid/linux-2.6 main/experimental/linux-2.6 main/sarge releases people This layout removes the indicator, where changes may be introduced without breaking too much. experimental seems like a pretty fair indication. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 10:46:43AM +0200, Sven Luther wrote: They could be releases/sid/linux-nonfree-2.6 and releases/sid/arch/mips/linux-patch-2.6.12-mips ? What do you want to do with the contents of utils? We currently differentiate between kernel themself, documentation and support utils. Depends on what you mean with developed. We saw that it is not possible to get regular testbuilds of the repository version and I broke 3 uploads because of this. If we want to be able to regulary push working versions into testing, we can't just push unchecked changes into this tree. This means that the sid tree can't be the development tree. Well, but we still need the sid tree fairly available to make bug fixes and such, but yes, it definitively makes sense to have both a sid and an experimental tree. Most of the changes can go to the development tree first and merged back from them. (Take a look at the subversion project, you'll get killed if you commit directly to a release branch if you do that without explicit approval.) Maybe we could even do daily-builds out of the experimental tree or something ? This will help. But we should begin to disable arches where we don't have a possitive result. arm currently don't have any developer machine for example. Bastian -- Deflector shields just came on, Captain. signature.asc Description: Digital signature
Re: SVN layout
On Thu, Aug 25, 2005 at 05:54:30PM +0900, Horms wrote: This layout removes the indicator, where changes may be introduced without breaking too much. experimental seems like a pretty fair indication. Only if you do regular cleanups of not longer used trees. Otherwise you remain with sid/bla experimental/bla but the development is done in sid/bla. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 signature.asc Description: Digital signature
Re: SVN layout
On Thu, Aug 25, 2005 at 11:33:08AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 05:54:30PM +0900, Horms wrote: This layout removes the indicator, where changes may be introduced without breaking too much. experimental seems like a pretty fair indication. Only if you do regular cleanups of not longer used trees. Otherwise you remain with sid/bla experimental/bla but the development is done in sid/bla. I believe part of the proposal is that development kernels are targeted for experimental. And the sid ones are a bit more stable. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 02:14:53PM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 07:02:13PM +0900, Horms wrote: I believe part of the proposal is that development kernels are targeted for experimental. And the sid ones are a bit more stable. This applies only to some packages. I guess they don't need an experimental branch then. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
Horms [EMAIL PROTECTED] writes: On Thu, Aug 25, 2005 at 11:33:08AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 05:54:30PM +0900, Horms wrote: This layout removes the indicator, where changes may be introduced without breaking too much. experimental seems like a pretty fair indication. Only if you do regular cleanups of not longer used trees. Otherwise you remain with sid/bla experimental/bla And why not use trunk for development and then a branch for sid? This is more or less how XSF works nowadays. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
On Thu, Aug 25, 2005 at 04:56:14PM -0300, Otavio Salvador wrote: Horms [EMAIL PROTECTED] writes: On Thu, Aug 25, 2005 at 11:33:08AM +0200, Bastian Blank wrote: On Thu, Aug 25, 2005 at 05:54:30PM +0900, Horms wrote: This layout removes the indicator, where changes may be introduced without breaking too much. experimental seems like a pretty fair indication. Only if you do regular cleanups of not longer used trees. Otherwise you remain with sid/bla experimental/bla And why not use trunk for development and then a branch for sid? This is more or less how XSF works nowadays. Far too much of a big deal is being made of this. Here is the problem in a nutshell. We have a number of different versions of different kernels. For some sarge is the head branch, for some sid is, and for some experimental is. The typical SVN layout (which people seem mildly obsessed with), puts whatever happens to be the head branch in trunk, and everything else in branch - in our case per-distribution branches. This isn't a big deal, except when stuff disappears into branch, when you expect it to be in trunk. It is also a bit confusing, when, say linux-2.6 in trunk was sid yesterday, and today its experimental and the sid version has mysteriously moved into branches. So an idea that many of the people in the kernel team seem comfortable with is moving everything that we are working on into trunk. Then there is some debate about perhaps renaming trunk (mainly to avoid the conitations that has), and how exactly to organise the distributions within trunk. One issue, that both approaches do not address very well, is the which branch is head problem. As I mentioned above, for some kernels its sid, for some its experimental (or perhaps we just don't release ones in that category) and for some its sarge. To be quite honest, I am more worried about making sure changes get put into all applicable branches, for instance a security fix, often needs to go into all branches, sometimes of all kernels. So it would be nice to make it really obvious where they all are. And not have head and branches in completely different places. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New SVN layout.
Hello, as explained earlier, i moved the subversion layout to be : kernel/trunk/kernel/powerpc kernel/trunk/kernel/source kernel/trunk/kernel-2.4/powerpc kernel/trunk/utils/initrd-tools and then the tags to somethign like. kernel/tags/kernel/powerpc/2.6.7-3 iand the branches to : kernel/branches/utils/initrd-tools/rel-0-1-32woody This means that it is now possible to checkout the whole trunk without bothering about tags and branches. You will find also a small README file in kernel/trunk, which explains this stuff. I reproduce it here : Some basic instructions : Initial checkout : svn co svn+ssh://user@svn.debian.org/svn/kernel/trunk Updating a checked out repository : svn update (in the directory of the repository) Checkin in changes : svn ci (in the directory of the repository) Adding files : svn add file or dir name Creating dirs : svn mkdir newdir Moving files or dirs : svn mv ildname newname Tagging after an upload : svn cp svn+ssh://user@svn.debian.org/svn/kernel/trunk/kernel/2.6/powerpc \ svn+ssh://user@svn.debian.org/svn/kernel/tags/kernel/2.6/powerpc/2.6.7-3 Branching : svn cp svn+ssh://user@svn.debian.org/svn/kernel/trunk/kernel/2.6/powerpc svn+ssh://user@svn.debian.org/svn/kernel/branches/kernel/2.6/powerpc/mybranch Exporting before an upload : svn export svn+ssh://user@svn.debian.org/svn/kernel/trunk/kernel/2.6/powerpc \ /path/to/build/dir Upload procedure : 1) Change the changelog entry from UNRELEASED to unstable. 2) export the package. 3) go into the exported dir and do the build 4) upload. 5) checkin the changes. 6) tag the package. Changelog practice : When making a change in a package, without having it uploaded, please put the changelog entry to UNRELEASED instead of unstable. When doing the upload this UNRELEASED is changed back to unstable. Friendly, Sven Luther
