qmail toaster development (non-public)

Jake Vickers | 23 Nov 2009 15:53

[qmailtoaster-devel] QMT Subversion schema

I've been trying to come up with a subversion repo schema for the QMT 
"stable" packages for development. What do you think of this layout:

-|
 |-trunk (latest SRPMS, with old versions being removed when new 
versions are released)
 |
 |-vpopmail-toaster
     \-SPECS
     \-SOURCES
 |
 |-daemontools-toastter
     \-SPECS
     \-SOURCES
 |
 |-courier-authlib-toaster
     \-SPECS
     \-SOURCES

and so on. I think by putting the SPECS and SOUCRES dir in subversion 
like this we can control progress and automate build scripts a little 
easier than the method I use now.
This would only apply to the current stable development. There would be 
open checkouts, and approved developers would be able to check in 
changes. Ultimately I want to keep the actual package build process 
monolithic at this point with the expectation that if it works well for 
the project to make that process more automated as well.

Any one want to throw some ideas into the pool on this or have other 
schema ideas?

(Continue reading)

Eric Shubert | 23 Nov 2009 20:40

Re: [qmailtoaster-devel] QMT Subversion schema

Jake Vickers wrote:
> I've been trying to come up with a subversion repo schema for the QMT 
> "stable" packages for development. What do you think of this layout:
> 
> -|
> |-trunk (latest SRPMS, with old versions being removed when new versions 
> are released)
> |
> |-vpopmail-toaster
>     \-SPECS
>     \-SOURCES
> |
> |-daemontools-toastter
>     \-SPECS
>     \-SOURCES
> |
> |-courier-authlib-toaster
>     \-SPECS
>     \-SOURCES
> 
> 
> and so on. I think by putting the SPECS and SOUCRES dir in subversion 
> like this we can control progress and automate build scripts a little 
> easier than the method I use now.
> This would only apply to the current stable development. There would be 
> open checkouts, and approved developers would be able to check in 
> changes. Ultimately I want to keep the actual package build process 
> monolithic at this point with the expectation that if it works well for 
> the project to make that process more automated as well.
>

(Continue reading)

Jacob Vickers | 24 Nov 2009 02:08

Re: [qmailtoaster-devel] QMT Subversion schema

> Jake Vickers wrote:
>> I've been trying to come up with a subversion repo schema for the QMT
>> "stable" packages for development. What do you think of this layout:
>>
>> -|
>> |-trunk (latest SRPMS, with old versions being removed when new versions
>> are released)
>> |
>> |-vpopmail-toaster
>>     \-SPECS
>>     \-SOURCES
>> |
>> |-daemontools-toastter
>>     \-SPECS
>>     \-SOURCES
>> |
>> |-courier-authlib-toaster
>>     \-SPECS
>>     \-SOURCES
>>
>>
>> and so on. I think by putting the SPECS and SOUCRES dir in subversion
>> like this we can control progress and automate build scripts a little
>> easier than the method I use now.
>> This would only apply to the current stable development. There would be
>> open checkouts, and approved developers would be able to check in
>> changes. Ultimately I want to keep the actual package build process
>> monolithic at this point with the expectation that if it works well for
>> the project to make that process more automated as well.
>>

(Continue reading)

Steve Huff | 23 Nov 2009 21:29

Re: [qmailtoaster-devel] QMT Subversion schema


On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:

> I've been trying to come up with a subversion repo schema for the  
> QMT "stable" packages for development. What do you think of this  
> layout:
>
> -|
> |-trunk (latest SRPMS, with old versions being removed when new  
> versions are released)
> |
> |-vpopmail-toaster
>    \-SPECS
>    \-SOURCES
> |
> |-daemontools-toastter
>    \-SPECS
>    \-SOURCES
> |
> |-courier-authlib-toaster
>    \-SPECS
>    \-SOURCES

i'd recommend something more like this:

/
sources/
         vpopmail-5.4.27.tar.bz2
         clamav-0.95.4.tar.gz
         ...

(Continue reading)

Jacob Vickers | 24 Nov 2009 02:25

Re: [qmailtoaster-devel] QMT Subversion schema

>
> On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:
>
>> I've been trying to come up with a subversion repo schema for the
>> QMT "stable" packages for development. What do you think of this
>> layout:
>>
>> -|
>> |-trunk (latest SRPMS, with old versions being removed when new
>> versions are released)
>> |
>> |-vpopmail-toaster
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-daemontools-toastter
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-courier-authlib-toaster
>>    \-SPECS
>>    \-SOURCES
>
> i'd recommend something more like this:
>
> /
> sources/
>          vpopmail-5.4.27.tar.bz2
>          clamav-0.95.4.tar.gz
>          ...

(Continue reading)

Steve Huff | 24 Nov 2009 17:13

Re: [qmailtoaster-devel] QMT Subversion schema

On Nov 23, 2009, at 8:25 PM, Jacob Vickers wrote:

> A point - at this time, QTP is a separate repo, but migrating into 1  
> tree
> may be something to look at if we restructure a few things. Not sure  
> how
> this would sync with the current Trac page that QTP runs. I do not  
> want to
> use Trac for QMT at this time.

doesn't matter, thanks to the magic of svn:externals!

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals

> Also, does anyone know how well this all integrates with  
> Sourceforge? I
> have a project checked out there for QMT, and would like to utilize  
> some
> of their resources (mainly file access/bandwidth). I imagine  
> Sourceforge
> has to integrate with subversion reasonably well....

Sourceforge has robust Subversion support.  here's a relevant blog  
post (that also talks about externals):

http://bitworking.org/news/Sourceforge__Subversion_and_svn_externals

i use Sourceforge for a few small projects, and i've had no issues  
with their Subversion service.

(Continue reading)

Jacob Vickers | 26 Nov 2009 01:55

Re: [qmailtoaster-devel] QMT Subversion schema

>
> On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:
>
>> I've been trying to come up with a subversion repo schema for the
>> QMT "stable" packages for development. What do you think of this
>> layout:
>>
>> -|
>> |-trunk (latest SRPMS, with old versions being removed when new
>> versions are released)
>> |
>> |-vpopmail-toaster
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-daemontools-toastter
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-courier-authlib-toaster
>>    \-SPECS
>>    \-SOURCES
>
> i'd recommend something more like this:
>
> /
> sources/
>          vpopmail-5.4.27.tar.bz2
>          clamav-0.95.4.tar.gz
>          ...

(Continue reading)

Steve Huff | 26 Nov 2009 13:31

Re: [qmailtoaster-devel] QMT Subversion schema

On Nov 25, 2009, at 7:55 PM, Jacob Vickers wrote:

> I'll think on this and try and come up with some more questions in my
> turkey-induced fugue, but to get a jump on this since you've been  
> using
> the schema for a while (at least you gave that impression), can you  
> tell
> us what problems you *have* encountered with this? I imagine we  
> would need
> a "developer manual" outlining the commands and procedures that would
> probably be best put on the wiki so we can circumvent the learning  
> curve.

hm.  the closest thing to a "problem" i can think of is that every  
time i create a new package i have to run `svn mkdir <packagename> &&  
svn mkdir <packagename>/trunk <packagename>/tags <packagename>/ 
branches && svn commit -m 'setting up TTB for <packagename>'`, which  
is a little onerous; i really should write a script to automate that  
task :)

> Also, have you used this method with the external repos, and what
> challenges did you face in that scenario?

yes; i have several externals definitions in my personal repo.  here  
are some examples:

1) i have some documentation written in DocBook, and one of the tools  
i use with DocBook is a Java program called fop.  i have an external  
definition pointing to the current trunk of fop that lives in my

(Continue reading)

Eric Shubert | 26 Nov 2009 11:35

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
> 
> On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:
> 
>> I've been trying to come up with a subversion repo schema for the QMT 
>> "stable" packages for development. What do you think of this layout:
>>
>> -|
>> |-trunk (latest SRPMS, with old versions being removed when new 
>> versions are released)
>> |
>> |-vpopmail-toaster
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-daemontools-toastter
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-courier-authlib-toaster
>>    \-SPECS
>>    \-SOURCES
> 
> i'd recommend something more like this:
> 
> /
> sources/
>         vpopmail-5.4.27.tar.bz2
>         clamav-0.95.4.tar.gz
>         ...

(Continue reading)

Eric Shubert | 26 Nov 2009 12:45

Re: [qmailtoaster-devel] QMT Subversion schema

Eric Shubert wrote:
> Steve Huff wrote:
>>
>> On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:
>>
>>> I've been trying to come up with a subversion repo schema for the QMT 
>>> "stable" packages for development. What do you think of this layout:
>>>
>>> -|
>>> |-trunk (latest SRPMS, with old versions being removed when new 
>>> versions are released)
>>> |
>>> |-vpopmail-toaster
>>>    \-SPECS
>>>    \-SOURCES
>>> |
>>> |-daemontools-toastter
>>>    \-SPECS
>>>    \-SOURCES
>>> |
>>> |-courier-authlib-toaster
>>>    \-SPECS
>>>    \-SOURCES
>>
>> i'd recommend something more like this:
>>
>> /
>> sources/
>>         vpopmail-5.4.27.tar.bz2
>>         clamav-0.95.4.tar.gz

(Continue reading)

Steve Huff | 26 Nov 2009 13:51

Re: [qmailtoaster-devel] QMT Subversion schema

On Nov 26, 2009, at 5:35 AM, Eric Shubert wrote:

> 1) Examples? I'm eager to see them.

http://code.google.com/p/rabbitvcs/source/browse/

here's a project that uses the TTB scheme.  my recommendation,  
essentially, is to view each package in qmailtoaster as a "project"  
along these lines.  in the spirit of full disclosure, i should mention  
that this is *totally* not my idea, but rather taken wholesale from
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout 
.

> 7) Wouldn't that be `svn diff vpopmail-toaster/tags/≤version1>  
> vpopmail-toaster/tags/≤version2>` ? (or am I missing something?)

you are absolutely correct.

> Regarding upstream sources, I'm wondering if there isn't a better  
> way for us to handle them. While I like having them outside of the  
> toaster package trees, it might be nice to have at least their tags  
> branches (and maybe trunk as well) expanded in their own package  
> trees, so that they can be browsed like other sources. Storing  
> compressed tarballs in svn sort of defeats the purpose of having  
> them in svn to begin with. If we did this, we'd see (for example):
> vpopmail/
> 	trunk/
> 	tags/
> 		5.4.17/

(Continue reading)

Eric Shubert | 26 Nov 2009 15:13

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
> 
> On Nov 26, 2009, at 5:35 AM, Eric Shubert wrote:
> 
>> Regarding upstream sources, I'm wondering if there isn't a better way 
>> for us to handle them. While I like having them outside of the toaster 
>> package trees, it might be nice to have at least their tags branches 
>> (and maybe trunk as well) expanded in their own package trees, so that 
>> they can be browsed like other sources. Storing compressed tarballs in 
>> svn sort of defeats the purpose of having them in svn to begin with. 
>> If we did this, we'd see (for example):
>> vpopmail/
>>     trunk/
>>     tags/
>>         5.4.17/
>>         5.4.28/
>>         5.5.0/
> 
> just for sanity i'd do
> 
> vpopmail/
>          trunk/
>                vpopmail.spec
>                src/
>                    <current vpopmail source>
>          tags/
>               5.4.17/
>                      vpopmail.spec
>                      vpopmail-whatever.patch
>                      src/

(Continue reading)

Jake Vickers | 30 Nov 2009 07:26

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
>
> On Nov 23, 2009, at 9:53 AM, Jake Vickers wrote:
>
>> I've been trying to come up with a subversion repo schema for the QMT 
>> "stable" packages for development. What do you think of this layout:
>>
>> -|
>> |-trunk (latest SRPMS, with old versions being removed when new 
>> versions are released)
>> |
>> |-vpopmail-toaster
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-daemontools-toastter
>>    \-SPECS
>>    \-SOURCES
>> |
>> |-courier-authlib-toaster
>>    \-SPECS
>>    \-SOURCES
>
> i'd recommend something more like this:
>
> /
> sources/
>         vpopmail-5.4.27.tar.bz2
>         clamav-0.95.4.tar.gz
>         ...

(Continue reading)

Steve Huff | 30 Nov 2009 13:49

Re: [qmailtoaster-devel] QMT Subversion schema

On Nov 30, 2009, at 1:26 AM, Jake Vickers wrote:

> I/we would need some "helper" scripts to automate some tasks, as  
> Steve has alluded to needing to do himself. Maybe add another  
> "package section" for helper scripts with a trunk release as well.  
> Thoughts on this?

RPMforge has a '/tools' area at the root of the repo which contains  
the various custom tools build for the project's internal use; such an  
area seems a good solution to this problem.

-steve

--

-- 
If this were played upon a stage now, I could condemn it as an  
improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es/

Eric Shubert | 30 Nov 2009 16:57

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
> 
> On Nov 30, 2009, at 1:26 AM, Jake Vickers wrote:
> 
>> I/we would need some "helper" scripts to automate some tasks, as Steve 
>> has alluded to needing to do himself. Maybe add another "package 
>> section" for helper scripts with a trunk release as well. Thoughts on 
>> this?
> 
> 
> RPMforge has a '/tools' area at the root of the repo which contains the 
> various custom tools build for the project's internal use; such an area 
> seems a good solution to this problem.
> 
> -steve
> 

I like this idea. And I'm willing to write some scripts.

--

-- 
-Eric 'shubes'

Jake Vickers | 1 Dec 2009 16:43

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
>
> On Nov 30, 2009, at 1:26 AM, Jake Vickers wrote:
>
>> I/we would need some "helper" scripts to automate some tasks, as 
>> Steve has alluded to needing to do himself. Maybe add another 
>> "package section" for helper scripts with a trunk release as well. 
>> Thoughts on this?
>
>
> RPMforge has a '/tools' area at the root of the repo which contains 
> the various custom tools build for the project's internal use; such an 
> area seems a good solution to this problem.
>

I would definitely like to reuse tools if at all possible rather than 
inventing new ones.
That being said, can I get some help from you (Steve) on setting up the 
svn repo? I'm familiar with creating a repo, but have not had the 
experience you have had with it with having multiple projects under one 
repo with controlled access. I'd like to read some documentation on the 
topic, but a seasoned resource would be great as well.

Another question - how have you handled backups of your repos? I've had 
a couple repos barf on me, and while they were recoverable (to some 
degree at least) I think we should plan for some type of backup schema. 
Sure the data itself will be on everyone's machine who checks out the 
repo, but what about the transactional data from subversion itself?

Steve Huff | 1 Dec 2009 17:48

Re: [qmailtoaster-devel] QMT Subversion schema

On Dec 1, 2009, at 10:43 AM, Jake Vickers wrote:

> I would definitely like to reuse tools if at all possible rather  
> than inventing new ones.
> That being said, can I get some help from you (Steve) on setting up  
> the svn repo? I'm familiar with creating a repo, but have not had  
> the experience you have had with it with having multiple projects  
> under one repo with controlled access. I'd like to read some  
> documentation on the topic, but a seasoned resource would be great  
> as well.

my pleasure; let me know how you want to proceed.

> Another question - how have you handled backups of your repos? I've  
> had a couple repos barf on me, and while they were recoverable (to  
> some degree at least) I think we should plan for some type of backup  
> schema. Sure the data itself will be on everyone's machine who  
> checks out the repo, but what about the transactional data from  
> subversion itself?

the standard way to back up a Subversion repository is to use the  
`svnadmin dump` command; much like `mysqldump`, it takes a snapshot of  
a live repository that can be used to completely restore the  
repository if it is corrupted or destroyed.  since it's a svnadmin  
command, it has to be run *on the Subversion server*.

a backup script looks something like this:

#!/bin/bash

(Continue reading)

Jake Vickers | 2 Dec 2009 16:28

Re: [qmailtoaster-devel] QMT Subversion schema

Steve Huff wrote:
>
> On Dec 1, 2009, at 10:43 AM, Jake Vickers wrote:
>
>> I would definitely like to reuse tools if at all possible rather than 
>> inventing new ones.
>> That being said, can I get some help from you (Steve) on setting up 
>> the svn repo? I'm familiar with creating a repo, but have not had the 
>> experience you have had with it with having multiple projects under 
>> one repo with controlled access. I'd like to read some documentation 
>> on the topic, but a seasoned resource would be great as well.
>
> my pleasure; let me know how you want to proceed.

Thanks Steve. Let me get a couple things moved around and I'll get back 
to you.

>
>> Another question - how have you handled backups of your repos? I've 
>> had a couple repos barf on me, and while they were recoverable (to 
>> some degree at least) I think we should plan for some type of backup 
>> schema. Sure the data itself will be on everyone's machine who checks 
>> out the repo, but what about the transactional data from subversion 
>> itself?
>
>
> the standard way to back up a Subversion repository is to use the 
> `svnadmin dump` command; much like `mysqldump`, it takes a snapshot of 
> a live repository that can be used to completely restore the 
> repository if it is corrupted or destroyed.  since it's a svnadmin

(Continue reading)

Return

Return to gmane.mail.qmail.toaster.devel.

Project Web Page

qmail toaster development (non-public)

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane