RE: Subversion Vision and Roadmap Proposal

> > 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
Received on 2010-04-09 17:29:52 CEST