On Thursday, 20 October 2005 at 18:05, Qamly wrote:
> On 10/20/05, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
> > On 10/20/05, Qamly <[EMAIL PROTECTED]> wrote:
> > > Anyway, I fixed it now.  Sorry about this.  I also see there is really
> > > no way to 'delete' (obliterate), so I ended up killing all the files,
> > > and then just did a copy of the revision with the backports into
> > > tags/
> >
> > I really think we ought to restructure our repository to follow the
> > "standard" svn model. That means, current development in trunk/,
> > frozen snapshots in tags/, and dead-end or to-be-merged-in-later
> > development in branches/. It is really messed up now.
> I looked into this, and seems we would have to svnadmin dump
> everything out first, then use svnadmin load to fix it the way you
> prefer.  This will save all the info in the logs and what not.

What's the problem with doing something like the following?

svn delete svn://.../trunk
svn copy svn://.../branches/crossplatform svn://.../trunk
svn delete svn://.../branches/crossplatform

Doesn't need any external space, and keeps the history.

Oh, by the way, tags/ has no history. How exactly did you create
it? By manually adding all files?

> > > If revision 400 needs data set 459, then it can get that specific
> > > version.  Same with any branch that needs that specific set.
> >
> > So what if the release branch needs a bugfix for some data files that
> > are different in the development branch? This is not at all
> > implausible.
> We still could do this, and for every release, we tag the data, and if
> it needs changing, we do it this way.  Yes, we would have to backport
> some fixes doing it this way.

How do you want to tag it? Via a note saying "code revision XXX needs
data revision YYY"?

> Otherwise, I can see us eating up LOTS of HD space, and I am not sure
> at all what the limit is.

As long as you use SVN to copy the files, they should just use once
their size on the server.

If at first you don't succeed, you're doing about average.
                -- Leonard Levinson
Warzone-dev mailing list

Reply via email to