> 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
Sure it exists... the file in rev65 is the same one as in rev64. I'm not sure why you wouldn't deploy using all the files in a specific rev? One thing we do, which may be what you are looking for is put dependencies in the repository. So, in our lib folder we have version X of log4net.dll. This is allways used to build the deployment. If the devs decide to start using version x.1 they would update the binary in the lib folder. > 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? Subversion doesn't really work this way. You can basically ask for the file as it was in rev x. It may be the same in many revs of course. > Can anyone suggest a command that will check the file version You can use a tool like SubWCRev Program from the Tortoise project which will tag the header with the latest version that a file was modified in. BOb
