[bouncer-dev] Trac ready

Eric Searcy emsearcy at osuosl.org
Fri Feb 22 22:03:08 UTC 2008


On Jan 8, 2008, at 3:36 PM, Lance Albertson wrote:

> All-
>
> Thanks to Rudy Grigar (basic), we finally have a VM up and running  
> with
> Trac. We've changed bouncer.osuosl.org to point to the trac instance  
> so
> that will be the official page for it. The next step will be two  
> things:
>
> 1) Get an htpasswd2 username/password crypt from all of you for svn

Actually, we have account sign-ups enabled, so for now you can sign up  
for a Trac account, and this will give you access to the repository.

We will probably disable this once most of the devs have created  
accounts, future accounts can be granted by sending up an htpasswd line.

>
> 2) Get an svndump of the current project at Mozilla then work on  
> merging
> any other code you guys wanted to do.


I've merged in the code into /branches/mozilla.  Because I spliced the  
history so that it would be chronological, the revision numbers are  
different now, and as an additional precaution the uuid of the repo  
has been changed, so you'll have to check it out again to make changes.

Oh, and I have a couple comments/suggestions on how it looks like the  
past devs have been doing branches and tags.  First off, tags aren't  
branches!  Many people actually put in permissions restrictions to  
prevent changes to past tags, and here's why.  First off, since SVN  
doesn't actually support tags, it doesn't really have the ability to  
move a tag to point somewhere different.  Rather, you've created a  
branch (cheap copy, really) in the /tags folder and are now making  
changes to it.  When I was using certain repository tools, the tags  
devs had created were actually showing up as branches because of the  
changes in them.  Anyhow, that's beside the point.  The problem comes  
in when a client says that they are running the /tags/xyz version and  
are having an error, but you can't look at the repo and determine what  
they should upgrade to because that tag was changed 10 times.  This is  
why tags are usually used for concepts like version numbers, because  
when a release happens that tag *was* the snapshot of that release at  
that particular time, period.  Then, if someone using a checked out / 
tags/1.0.3 release wants to upgrade or reports a bug, we know exactly  
what set of files they have, and in order to have them upgrade all  
they have to do is rebase to /tags/1.2.5 (or whatever).  Things like  
`1.0-production' fit more in the concept of a branch because it  
receives further changes.  Unfortunately, in the case of bouncer the  
tags haven't just been having changes pulled over from trunk to move  
them, but *there has actually been development being done directly on  
the tags*.  That is, there are patches and changes to /tags/1.0- 
production (like the lstats csv.php include) that were never added to  
any of the 1.0 branches, just to this `tag'.  This was really  
confusing when I was trying to merge the history from multiple repos  
together, and I think we should probably enforce the `no commits to  
tags' policy with pre-commit check to prevent new patches from making  
their way to tags.

Anyhow, I wanted to bring that up, and perhaps get feedback from the  
devs on any reasons they might have to continue using these moving  
tags (even though the latter, tag-only commits, still needs to be done  
away with) before I set something up to enforce this.

/me gets off soapbox

-- 
Eric Searcy
OSU Open Source Lab




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osuosl.org/pipermail/bouncer-dev/attachments/20080222/d43fc70c/attachment.pgp 


More information about the bouncer-dev mailing list