> > P.S. Pleeeease, introduce true tags, no more "lets pretend this copy > is > > a tag". > > I agree here - branches are great, but sometimes you want a 'snapshot' > or a 'baseline' that doesn't require a whole new directory in the repo > (especially as the number of branches you have increases, things start > to become less manageable - just the nature of having lots of > things)(for example, we have 300 projects in our repo and we release > very regularly. Creating a branch for each release would be a bit messy > after just a few - not to mention the problems of deciding how to > structure the repo to account for all those projects, do we put branches > at the root and have a huge list of releases that require special naming > conventions, or branch at the project level and miss the > interdependencies between them. All tricky stuff for the branching > mechanism).
I for one totally agree with this. I can see the copy command being broken up into three commands, branch, fork, tag. I think the huge win would be branch. Sure, internally it would be a copy. But... a property on the branch folder to indicated it is a branch. Also, the merge command should be modified to ensure that all merges were treated as if they are done and the root folder of the branch. While there is a lot of flexibility with the current scheme... with flexibility adds complexity. And, I agree with what someone else said here or on another thread. People aren't using Git/Hg because it is distributed they are using it because it is FAST and Branches and Tags are first class citizens. I am guessing most teams using Git/Hg do have a central repository that is the "one true copy" of the project which build servers and code reviews, etc all go through. I man, the popularity of this is evidenced by the popularity of GitHub. BOb
