On 07/03/07, Marcus Rueckert <[EMAIL PROTECTED]> wrote:
> On 2007-03-07 10:34:47 +0000, Dave Shield wrote:
> > In particular, I propose the following:
> > b) Move the following to a new directory ('closed')
> > V3-line
> > V4-0-line
> > V4-1-1-patches,
> > V4-2-patches,
> > V5-0-patches
>
> just delete them. you can undo the deletion if needed in
> one svn merge cmdline.
I'd rather keep them immediately accessible Just In Case.
I've been told that the SVN view is Branches are Cheap, and
the More the Merrier.
Certainly for the last two - the earlier ones are probably
less important.
> > V5-1-patches
>
> can we leave that open for a bit more time. i could at least
> put all the our patches for 5.1 into it.
The 5.1.x line is officially closed so it ought to be treated
in the same way as the 4.2.x and 5.0.x lines.
It might be sensible to apply those patches (maybe to
5.0.x as well?), although we wouldn't normally expect
to make another release on either of these lines.
> > b') Move the following to either b) or c):
> > V-5-0-10-patches (rename to V5-0-10-patches?)
> > V-5-2-1-patches (rename to V5-2-1-patches?)
> > V5-1-3-patches
> > V5-3-0-patches
>
> what makes those branches different to the branches in a) ?
The branches listed in a) are the current end points
of the lines that are still being actively developed.
So we're working with them on an (almost) daily basis.
The branches listed in b) are the current end points
of lines that have been closed. We wouldn't normally
expect to do anything more on these branches, but
they would be the starting point if we ever did decide
to make another release of those lines.
I believe that these branches listed as b') are spurs,
relating to a particular release. I'm not quite sure of
the exact history - which is why I listed them separately,
with a choice of treating them as either b) or c)
> > c) Move all remaining branches to a new directory ('old')
> > d) Delete some/all branches from c)
>
> just delete the unused branches. you can undo the deletion if needed in
> one svn merge cmdline. i would only keep them directly visible if you
> need them (to lookup stuff or so)
My preference would be to delete them altogether.
But I listed this as two separate steps to allow for
partial disagreement.
> > 2) tags:
> > a) Retain all [full-release] tags... as currently
> > b) Move[/Delete] all [pre-release] tags
> > c[/d]) Move[/Delete] all remaining tags
> many of those "tags" seems to be kind of release branches.
> i would just delete them.
I'm hestitant to delete the tags for full releases.
We don't often need to refer to a particular release,
but it's not unheard-of. And if SVN tags are as cheap
as I'm led to believe, why not keep them?
> I doubt anyone is interested in tags for some prerelease
> stuff.
That's my feeling too. (See below)
Perhaps keep the most recent set of pre-release snapshots
for each line, but I don't see the need to keep all the earlier ones.
> > I'm also inclined to drop all the pre-release tags
> > once the corresponding full release has been made.
> > But separating these out from the full releases
> > would be a reasonable compromise, if it was felt
> > worth keeping them.
>
> what arguments do you have for keeping them?
Me?
I don't have any arguments for keeping them at all!
I'm trying to anticipate possible objections from
elsewhere.....
Does anyone else have any thoughts on any of this?
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
