You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Henrik Sundberg <st...@gmail.com> on 2008/03/03 12:21:50 UTC
How to handle document status?
Hi,
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?
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to handle document status?
Posted by Toby Thain <to...@telegraphics.com.au>.
On 6-Mar-08, at 7:18 PM, Kevin Grover wrote:
>
>
> On Thu, Mar 6, 2008 at 12:02 PM, Henrik Sundberg
> <st...@gmail.com> wrote:
> 2008/3/4, Thomas Hemmer <th...@go-engineering.de>:
> > 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)
>
>
> You could just branch it: either create an /approved directory off
> the main directory ... You could even set svn:needs-lock on those
> files so that they are not easily modified.
Or mark ready only with path based access control.
--Toby
>
>
> - Kevin
Re: How to handle document status?
Posted by Kevin Grover <ke...@kevingrover.net>.
On Thu, Mar 6, 2008 at 12:02 PM, Henrik Sundberg <st...@gmail.com>
wrote:
> 2008/3/4, Thomas Hemmer <th...@go-engineering.de>:
> > 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)
>
>
You could just branch it: either create an /approved directory off the main
directory (or you could put in /branches/approved, or even
/tags/approved). 'branches' is probably not the best place, because, by
custom, those files are not considered 'fixed'.
You could then also filter on the path in hooks.
Or, you could attach your own property mycompany:status and set it to
'approved' when that's the case. This is easy to test for. You could even
set svn:needs-lock on those files so that they are not easily modified.
- Kevin
RE: How to handle document status?
Posted by Thomas Hemmer <th...@go-engineering.de>.
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@gmail.com]
> Sent: Thursday, March 06, 2008 9:03 PM
> To: users@subversion.tigris.org
> Subject: Re: How to handle document status?
>
> 2008/3/4, Thomas Hemmer <th...@go-engineering.de>:
> > > -----Original Message-----
> > > From: Henrik Sundberg [mailto:storangen@gmail.com]
> >
> > > Sent: Monday, March 03, 2008 4:48 PM
> > > To: users@subversion.tigris.org
> >
> > > Subject: Re: How to handle document status?
> > >
> > > 2008/3/3, Thomas Hemmer <th...@go-engineering.de>:
> > > > > From: Henrik Sundberg [mailto:storangen@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@subversion.tigris.org
> For additional commands, e-mail: users-help@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
Re: How to handle document status?
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/4, Thomas Hemmer <th...@go-engineering.de>:
> > -----Original Message-----
> > From: Henrik Sundberg [mailto:storangen@gmail.com]
>
> > Sent: Monday, March 03, 2008 4:48 PM
> > To: users@subversion.tigris.org
>
> > Subject: Re: How to handle document status?
> >
> > 2008/3/3, Thomas Hemmer <th...@go-engineering.de>:
> > > > From: Henrik Sundberg [mailto:storangen@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to handle document status?
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/3, Thomas Hemmer <th...@go-engineering.de>:
> > From: Henrik Sundberg [mailto:storangen@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?
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How to handle document status?
Posted by Thomas Hemmer <th...@go-engineering.de>.
Henrik,
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.
Hope this helps,
Thomas
> -----Original Message-----
> From: Henrik Sundberg [mailto:storangen@gmail.com]
> Sent: Monday, March 03, 2008 1:22 PM
> To: users@subversion.tigris.org
> Subject: How to handle document status?
>
> Hi,
>
> 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?
>
> /$
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@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