Does an easy way exist to find out what point in trunk history was the starting point of a particular branch (what was the point from which the branch was derived)?
Assume, that branch folder name does not carry the necessary information.
I cannot find any reference to the point in trunk history, from where the branch was derived and in branch history too.
What trunk version the branch was derived from?
Moderator: SourceGear
Re: What trunk version the branch was derived from?
Would it be possible to display in the trunk's history ("trunk" being the folder that the branch was created from) a record showing where branches were created? Even better, if the system created a label against the trunk at this point, as then all the "compare labels" functionality would be available.talamar wrote:I cannot find any reference to the point in trunk history, from where the branch was derived and in branch history too.
A related question - when you sync a branch against the trunk Vault doesn't seem to record it. Would that be possible to do, even if its again just another system-generated label?
Lastly, it'd be _really_ nice if Vault could support labels that floated with the Tip
"Floating" labels are always associated with the newest revision of the branch to which they is applied, rather than being anchored to one particular revision. If you applied a floating label to a trunk revision, then that floating label would move whenever a new revision is added so that it always points to the newest trunk revision. If a floating label is applied to a branch, then it will always point to the tip revision on that branch.
When you created a new Label you'd have a checkbox on the dialog saying whether it should float or not. Ideally there'd be a means of accessing the properties of a floating label later on to make it "fixed".
With our old system (PVCS) we commonly used floating labels for automated scripts that created the overnight build. There's workarounds for it of course, but it'd be nice to have. Quite a few other VCS's have floating labels as well - not that that should influence your decision on whether they should be added to Vault
While on the topic of labels, when we're getting close to a major build (for handover to the testing group for instance), we used to be able to put a label on the code & then advance it to include new changes as they're added until we're happy that the build is ok. That way we can always extract the latest version of the code for the major build, which may or may not include all Tip changes, by getting the label.
I know that Vault has "Label Promotion", but this works at an individual file level. From what I've been able to discover, there's no way of advancing a label to include new changesets, which I think would be more useful (for our purposes anyway). If there's a way of doing it then I'd be very happy to find out
When you created a new Label you'd have a checkbox on the dialog saying whether it should float or not. Ideally there'd be a means of accessing the properties of a floating label later on to make it "fixed".
With our old system (PVCS) we commonly used floating labels for automated scripts that created the overnight build. There's workarounds for it of course, but it'd be nice to have. Quite a few other VCS's have floating labels as well - not that that should influence your decision on whether they should be added to Vault
While on the topic of labels, when we're getting close to a major build (for handover to the testing group for instance), we used to be able to put a label on the code & then advance it to include new changes as they're added until we're happy that the build is ok. That way we can always extract the latest version of the code for the major build, which may or may not include all Tip changes, by getting the label.
I know that Vault has "Label Promotion", but this works at an individual file level. From what I've been able to discover, there's no way of advancing a label to include new changesets, which I think would be more useful (for our purposes anyway). If there's a way of doing it then I'd be very happy to find out
I've added both suggestion to our list of requests.
F: 13546, 13545
On the first one though, to get the latest code, one only has to perform a Get on a parent folder. Does that not accomplish what you are looking for?
On promoting a changeset, I'm assuming you mean that whatever versions of the files that changeset created are the file versions that should get promoted then. If that's not what you mean, just let me know.
F: 13546, 13545
On the first one though, to get the latest code, one only has to perform a Get on a parent folder. Does that not accomplish what you are looking for?
On promoting a changeset, I'm assuming you mean that whatever versions of the files that changeset created are the file versions that should get promoted then. If that's not what you mean, just let me know.
Sorry Beth, I didn't noticed your replies. Yes, your summary of my request re changesets & promotion is correct. Deleting & re-creating the label ad that changeset version won't work if other changesets have been committed since the label's initial creation that I _don't_ want the label to include.
I think this has been described in more detail in some other threads recently...
I think this has been described in more detail in some other threads recently...