2008/3/4, Thomas Hemmer <themmer_at_go-engineering.de>:
> > -----Original Message-----
> > From: Henrik Sundberg [mailto:storangen_at_gmail.com]
>
> > Sent: Monday, March 03, 2008 4:48 PM
> > To: users_at_subversion.tigris.org
>
> > Subject: Re: How to handle document status?
> >
> > 2008/3/3, Thomas Hemmer <themmer_at_go-engineering.de>:
> > > > From: Henrik Sundberg [mailto:storangen_at_gmail.com] > In our
> > > current process documents are marked with their state, >
> > eg Draft or
> > > Approved.
> > > >
> > > > I think it is a bad idea to modify the documents at approval >
> > > (the approval should not change the thing it approves).
> > > >
> > > > I was thinking of adding a property for this, eg ApprovedBy.
> > > >
> > > > But. As soon as someone updates an approved document it
> > > should
> > > revert to being a draft.
> > > > Forbidding modification of approved documents in the >
> > pre-commit
> > > hook will only partly solve the problem, because > it
> > would force the
> > > updater to remove the property for the > approved version. I just
> > > want to remove it for the new version.
> > > >
> > > > Removing the property in the post-commit hook is
> > tempting, > but
> > > considered not ok since it would make the committed > version
> > > different from the working copy.
> > > >
> > > > Is there a better way to handle this?
> >
> > > my first guess would be to treat your documents exactly
> > the same way
> > > program sources are handled, i. e. the "approved" state would be
> > > reflected by pulling an "svn cp" of that very document from
> > the trunk
> > > into some "tags" directory.
> > > All further work on the document would happen within the trunk,
> > > leaving the once approved versions untouched.
> >
> > Thanks. I might need to do this but it is a little troublesome.
> > I have ~200 components each with 4-10 official documents. I
> > intend to let the documents live in the trunk in a directory
> > parallel to the code. I'd like it to be possible to review
> > and approve individual documents and then when everything is
> > ok, make a component release
> > (tag) of the total. If the documents are tagged separately,
> > I'd have problem to see their state in the component release.
> >
> > Does it make sense? Can this be handled in a nice way?
> >
> > /$
> maybe I have not fully understood your requirements.
> Sounds like if you were performing some kind of multi-stage release
> process?
> Provided this were your very use case, the solution could be to
> introduce different tag directories "to be approved" and "approved".
Thanks for your patience.
We decided to test another, unorthodox method.
When something is approved we add an -approved suffix.
Ie: svn mv test.odf test-approved.odf
I can easily prohibit modification to approved documents in the
pre-commit. And an approved document will be seen as approved no
matter how it is copied in the structure.
And when updetes are needed we'll start with renaming the document again.
Do you expect me to get in trouble due to this solution?
Is this dangerous now, but will be safe in the 1.5 release (I've read
about better rename handling)
/$
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-06 21:03:22 CET