On Thu, Jan 14, 2010 at 11:30, Headley, Ronald (PSC/ISMS/EAD-CTR) <ronald.head...@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.
