On Thu, Jan 14, 2010 at 11:30, Headley, Ronald (PSC/ISMS/EAD-CTR)
<Ronald.Headley_at_psc.hhs.gov> wrote:
> Thanks Andy. We really want to work with a file version, or revision, as opposed to a tree revision. Suppose there are three revisions of File-1 in the repository and one revision of File-2.
>
> File-1 revision 63
> File-1 revision 64
> File-2 revision 65
> File-1 revision 66
>
> Suppose we want to deploy File-1 revision 66 but the developer specifies revision 65 (which doesn't exist) when creating the deployment package (HP Kintana). In this scenario, File-1 revision 64 will be exported and deployed. This is what happened and is what we want to avoid. Do you have any suggestions?
>
> Perhaps the wrong tool was selected or perhaps it is not setup correctly or we're not using it correctly. Either way, it is what we have to work with and we're trying to improve our processes. We're also looking at establishing baselines for our systems using SVN. Can this be done?
Subversion doesn't have "file revisions." Revision 65 *does* exist,
and File-1 *does* exist in that revision - it just wasn't changed
then, so it looks identical to File-1 in revision 64.
Each revision number represents the state of the entire repository at
that moment in time. If File-1 wasn't changed in revision 65, File-1 @
r65 will look identical to File-1 @ r64.
From your description (but I'm having a hard time understanding what
you're trying to achieve), Subversion may not be the right tool for
your requirements, or may require some significant layering of other
programs/scripts on top of it to get it to do what you want.
A "complex tag" may get you closer to where you want to be. See
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html#svn.branchmerge.tags.mkcomplex
Not sure what you're trying to do with "baselines" - is this for
detecting changes to items in (for example) a production environment?
That would be a better task for something like Tripwire.
Received on 2010-01-14 18:15:36 CET