Branching with Version 2.0.6
Moderator: SourceGear
Branching with Version 2.0.6
The situation i have is that i have pined some files a few versions back and i want to get a snap shot of the older version for Arching. I do this every time we have a version release incase we need to go back and work on the current version in production vs. our work in progress on the new version.
For example we have Version 1.4 in Archive and we are currently working on Version 1.6. We forgot to get a snap shot of Version 1.5, so i went through and pinned the versions that were part of 1.5. Then i went and branched (copy) the project. It did the branch but it pulled the version directly after the pin. For example if i pined Version 83 for a file in Vault it would grab version 84 even though there may be up to version 90. it was like this on all the files and i tried it a second time and had the same results.
Is this a bug in version 2.0.6 of Vault? Or, is this what it's suppose to do? The only other thing i can think of doing is get the latest version 1.5 and then readd that as a new project inside of vault within archive.
For example we have Version 1.4 in Archive and we are currently working on Version 1.6. We forgot to get a snap shot of Version 1.5, so i went through and pinned the versions that were part of 1.5. Then i went and branched (copy) the project. It did the branch but it pulled the version directly after the pin. For example if i pined Version 83 for a file in Vault it would grab version 84 even though there may be up to version 90. it was like this on all the files and i tried it a second time and had the same results.
Is this a bug in version 2.0.6 of Vault? Or, is this what it's suppose to do? The only other thing i can think of doing is get the latest version 1.5 and then readd that as a new project inside of vault within archive.
My guess is you probably branched for the 1.5 version, rather than ran a snapshot.asaxton wrote:Is this a bug in version 2.0.6 of Vault? Or, is this what it's suppose to do? The only other thing i can think of doing is get the latest version 1.5 and then readd that as a new project inside of vault within archive.
Is the folder of the 1.5 sub-tree pinned? Look at the history of the file w/ version 84. What does version 84 say for history?
Jeff Clausius
SourceGear
SourceGear
hmmm. Not sure about what a snap shot is.
Here is what i am doing. I have a top level folder called Web Applications. Under Web Applications i have my current working projects. These are the items that are under development. Also under Web Applications i have a folder called Archive. What i do is i will branch a currently working folder into the Archive folder and name it for the version that i am archiving.
Web Applications
-- Archive
---- FolderA v1.0
---- FolderA v1.1
---- FolderA v1.2
---- FolderA v1.3
---- FolderA v1.4
-- FolderA
in this case FolderA is actually Version 1.6 as we forgot to branch when we released Version 1.5. So i pinned the version of the files that went with version 1.5 and then i did the branch.
For FileA, i pinned version 83 of the file. It went up to version 90. In the Archived Folder it was showing version 84 which matched with version 84 in the current folder. it didn't pull version 83 at the latest.
I hope that makes sense.
Here is what i am doing. I have a top level folder called Web Applications. Under Web Applications i have my current working projects. These are the items that are under development. Also under Web Applications i have a folder called Archive. What i do is i will branch a currently working folder into the Archive folder and name it for the version that i am archiving.
Web Applications
-- Archive
---- FolderA v1.0
---- FolderA v1.1
---- FolderA v1.2
---- FolderA v1.3
---- FolderA v1.4
-- FolderA
in this case FolderA is actually Version 1.6 as we forgot to branch when we released Version 1.5. So i pinned the version of the files that went with version 1.5 and then i did the branch.
For FileA, i pinned version 83 of the file. It went up to version 90. In the Archived Folder it was showing version 84 which matched with version 84 in the current folder. it didn't pull version 83 at the latest.
I hope that makes sense.
You mentioned "snap shot" in your above posting, so I assumed you were using the "snap shot" operation from the GUI client's menu. It operates similar to branch, with a few differences ( like not incrementing the version of the snapshot item - version 83 == version 83 ).
However, when a file is branched, its version is "revved" to the next version, as a branch is normally used when you will be making modifications down a code path's branch. When you view the history of the file, version 84 should say it was created from a branch. However, if you diff versions 84 and 83, they will be the same file.
This is by design.
However, when a file is branched, its version is "revved" to the next version, as a branch is normally used when you will be making modifications down a code path's branch. When you view the history of the file, version 84 should say it was created from a branch. However, if you diff versions 84 and 83, they will be the same file.
This is by design.
Jeff Clausius
SourceGear
SourceGear
Are you planning to do any development ( or actively doing any development ) down any of these paths?asaxton wrote:So i'm not really sure what the best approach is to capturing a version.
If not, I'd strongly recommend using Label. And if you need it, you can share or branch the label back into the tree when it is needed. This keeps your repository from getting "junked" up with obsolete code paths.
Jeff Clausius
SourceGear
SourceGear
Do you happen to know a "date" for Version 1.5? If so, you could look at the version of a folder ( by version number ), select the version which you think represents the state of the sub folder at the time of Version 1.5, and branch or label on that folder's historical version.asaxton wrote:The only other thing i can think of doing is get the latest version 1.5 and then readd that as a new project inside of vault within archive.
This would save you the trouble of messing with the pins.
Jeff Clausius
SourceGear
SourceGear