Sorry for adding my two cents late.
First, I'm distinctively indifferent about the "<package>/{trunk,tags,
branches} vs {trunk,tags, branches}/<package>" issue. (FWIW, I think it
is a design deficiency in Subversion that it even forces us to _choose_
between the two.)
Joey Hess wrote:
> This is my proposal for the layout:
>
> [...]
> tools/
tools/ contains only the dh-make-perl package. Why is this even in tools/
rather than packages/ (resp. {trunk,tags,branches}/)? Is its status
really special enough to warrant this?
> [...]
> branches/
> upstream/
> libalias-perl/
> 2.32/
> current/
> ...
> soap-lite/
> 0.68/
> current/
Why branches/upstream/<package> instead of branches/<package>/upstream?
Not that I care a lot, but I'm interested.
> FWIW, this avoids most of svn-buildpackage's bugs with this style of
> repo layout. (Except for the svn-inject -l 2 bug.)
I'd really like by far most of the toolchain issues (that occur with the
new layout but not with the old=current one) ironed out before doing the
switch. Even after having read through this thread I'm not completely
certain whether there remain any significant issues. I trust the many
eyes of the DPG, though, so I assume we're good to go.
Gunnar Wolf wrote:
> Now that reorganizing our repo comes to the table again, I was
> thinking (based on a bit of experience with the pkg-ruby-extras team)
> that, given renames are cheap in SVN, we could also use the repo
> itself to signal when rebuilds/uploads are pending - i.e.,
> pkg-ruby-extras have two main trees, packages and packages-wip (Work
> In Progress). As you should expect, the packages in WIP are not yet
> ready to upload.
>
> I was thinking we could use packages-pending so that non-DDs would
> just copy the trunks they worked with over there. When a DD notices
> there is a package in -pending, he just assumes it is ready to be
> uploaded.
>
> Of course, we could also split packages-needhelp or something like
> that, where we can put our advances while working towards a bugfix or
> something like that.
>
> Does it sound usable, or just overengineering (we already have the
> list)?
Seems like overengineering to me. If we want to track status within the
repo, why not simply maintain a TODO (or similar) file in the repo's root
dir? `svn lock` may also be worth a look.
Besides, continuous `svn cp`ing and `svn rm`ing dirs is prone to causing
confusion when stuff has been checked out by people and then suddenly
disappears (via `svn rm`) from under their noses.
Finally, as a matter of principle, Subversion is not an issue tracker.
Joey Hess wrote:
> I will probably convert the repo this weekend, if that's still ok.
Can you tell about when, or will you send another notice to the list before
making the switch?
Julian.
Attachment:
pgpggT96WSpC_.pgp
Description: PGP signature