You might be able to write this to work with FSFS in an hour, but
certainly wouldn't work with BDB. Besides, I don't believe in "only an
hour" change. Changes must be tested, documented, retested, and tested
once more. To me, there is no such thing as a minor change.
Nor, I'm not too sure how "minor" a change it would be. On FSFS, it
seems to be a matter of removing a single directory and making a few
other changes, but if I was a developer, I'd insist that we would have
to program via the API, and that would add considerable development
overhead to the project. Plus, how would it affect developers who have
the version you've just removed as a working directory?
If you know the format of the FSFS archive, you could easily finagle
your way through deleting the latest versions. I'd backup my archive
first, then take down access to my archive while I manually muck
around with everything. And, there is still no guarantee that it would
be as clean as I thought.
Of course, the easiest way to undo the last commit is to checkout your
source into a working directory, export the previous version into
another directory, and copy the previous version over the last one,
and recommit. That way, you know that everything will workout in the
end. Developers would simply update their working directories to
receive the last valid version of the archive.
On 8/8/05, Holger Stratmann <tigris@finch.de> wrote:
> Hi Bob,
>
> thanks a lot for your help, but now it seems you haven't even read what
> I wrote...
>
> >Here is the project issue number on this problem....
> >Things are actually rather complicated.
> >
> What I'm talking about is a *completely* different thing!!!
> That's why I put *latest* in *bold* ;-))
>
> #1) It's not a "vertical" change (potentially affecting all prior
> revisions like "obliterating" a file from all previous revisions)
> #2) It does not affect any "newer" revisions (because there aren't any)
> that might be diffs against the one I'm trying to delete
>
> I still believe that:
>
> >My "entire" problem is about 4-6 bytes.
> >
> and - no offense intended or taken (!) - my view of things is not as
> naive as you seem to think :-)))
>
> I could possibly even do this with a post commit hook that copies the
> "current"-file to "backup/current.R[n] after every new revision.
>
> I guess I'll file a feature request for this. But of course I'll need
> some time to verify it's no duplicate and check with a new mail to the
> mailing list first... guess I won't have time to do that this week...
>
> Holger
>
>
>
> Bob Proulx wrote:
>
> >Holger Stratmann wrote:
> >
> >>To all: I think there "should" be a simpler solution - at least for fsfs!
> >>Actually, I could imagine that this "feature" could be implemented in
> >>svnadmin within something like an hour. (!! no, really!). Of course (?)
> >>it should be svnadmin and not svn client... (it *could* break working
> >>copies)
> >>
> >>After all, this is just about deleting a few (revision) files, nothing
> >>more! (and telling SubVersion that they don't exist any more)
> >>My "entire" problem is about 4-6 bytes. The "current" file starts with
> >>the current revision number in plain text and then about 5 more characters.
> >>
> >>Dumping and reloading an entire repository seems to be an awful solution
> >>for this...
> >>
> >>
> >>>Search the mailing list archives for "svnadmin" "dump" and "load" and
> >>>you should fine various examples. This is a very similar problem to
> >>>the one of changing underlying database formats.
> >>>
> >>I don't agree here. Changing the database format affects ALL data - and
> >>it affects data you want to keep.
> >>What I need is just deleting the latest additions (no problem at all in
> >>fsfs!) and then letting SubVersion know that they are gone...
> >>
> >
> >Here is the project issue number on this problem. Please read it to
> >see why this is really not a simple thing to do.
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=516
> >
> >And actually I should have suggested that you search for "obliterate"
> >too. There is at least a hundred postings deep discussing this issue
> >in this next thread.
> >
> > http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=313151
> >
> >Things are actually rather complicated.
> >
> >Bob
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 8 22:48:46 2005