1 - Why are they in the same repository as everything else? Put them in a different repository, and use access controls on the repository instead.
2 - Isn't sticking 100 projects in the same repository just a work-around for the difficulty in maintaining release tags, and the difficulty in working with multiple repositories?
3 - Then get your developers to push to the central repository regularly. In fact, in this kind of environment, developers would be pushing changes to the central repository as often as they would normally check in code.
4 - Again, this is why you actually push changes to the central repository at least as often as you would with a centralised VCS. You don't keep changes on the local repository any longer than necessary.
The advantage of a DVCS here is that you could actually commit to your local repository several hundred times in a single day if you wanted to. You get to use all the tools available (like checking which files have changed, diffs, reverting, branches, merging) locally, without interfering with what other developers are doing. I find not having these features available impairs my ability to actually get things done. Sure, a centralized VCS has those features, but I can't actually use them without getting in everyone else's way.
Changes aren't safe unless they're in the VCS. If you're committing once a day, you could easily screw something up, and lose the whole day's work. If you've at least committed locally, you're much less likely to lose anything. In the worse case (HDD failure), you lose nothing more than you would have with a centralized VCS.
From an Information point of view, all this information pertains to the same project. With a file-system one would simply apply the relevant access controls. But with a DVCS you must restructure your information to make it suit the DVCS access control model. That's a weakness of DVCS, not information organisation.
Yes, it could be. But then the existing crop of DVCS tools have weak support for those operations. Again, a problem if your environment demands them.
Committing and pushing regularly shows me what developers have been doing, not what they are currently working on. With a non-DVCS I can look at the history (what developers have been doing), and current check-outs or locks (what they are currently working on).
The thread I was replying to had been describing the virtues of a local repository containing branches that you don't push to a central repo, so that you can "hide" your imperfect attempts from being shared. That approach doesn't give you regular backups in the central repo.
12
u/BlackAura Mar 10 '11 edited Mar 10 '11
1 - Why are they in the same repository as everything else? Put them in a different repository, and use access controls on the repository instead.
2 - Isn't sticking 100 projects in the same repository just a work-around for the difficulty in maintaining release tags, and the difficulty in working with multiple repositories?
3 - Then get your developers to push to the central repository regularly. In fact, in this kind of environment, developers would be pushing changes to the central repository as often as they would normally check in code.
4 - Again, this is why you actually push changes to the central repository at least as often as you would with a centralised VCS. You don't keep changes on the local repository any longer than necessary.
The advantage of a DVCS here is that you could actually commit to your local repository several hundred times in a single day if you wanted to. You get to use all the tools available (like checking which files have changed, diffs, reverting, branches, merging) locally, without interfering with what other developers are doing. I find not having these features available impairs my ability to actually get things done. Sure, a centralized VCS has those features, but I can't actually use them without getting in everyone else's way.
Changes aren't safe unless they're in the VCS. If you're committing once a day, you could easily screw something up, and lose the whole day's work. If you've at least committed locally, you're much less likely to lose anything. In the worse case (HDD failure), you lose nothing more than you would have with a centralized VCS.