[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: How to handle document status?

From: Thomas Hemmer <themmer_at_go-engineering.de>
Date: Fri, 7 Mar 2008 10:52:45 +0100

Henrik,

I do not expect any possible source of trouble with your solution.
Even the fact that subversion "breaks" a rename into a copy/delete
sequence should not hurt you since the copied file retains the history
of the original one.
The only issue that might be confusing is that an 'svn log' on that file
does not directly reflect the "rename" operation. Although I don't know
exactly how the SVN folks solved the "rename" problem I pretty much
suppose that things will become even better with 1.5 ;-)

Best regards,

Thomas

> -----Original Message-----
> From: Henrik Sundberg [mailto:storangen_at_gmail.com]
> Sent: Thursday, March 06, 2008 9:03 PM
> To: users_at_subversion.tigris.org
> Subject: Re: How to handle document status?
>
> 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
>
>

GO Engineering GmbH - Stolzenbergstr. 13/IV - 76532 Baden-Baden
Geschäftsführer:
Helmut Gerstner, Dipl.-Ing. (FH)
Ralf Wörner, Dipl.-Ing. (FH)
Registergericht: Mannheim HRB 201811

---------------------------------------------------------------------
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-07 11:24:53 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.