Guten Tag Zé, am Samstag, 11. Mai 2013 um 19:45 schrieben Sie: > The existence of a branch shouldn't depend on whether > someone checked out an older revision or not, and creating a branch > shouldn't appear on any file's history. Essentially the people behind > all popular SCM projects understood this right from the start.
I have a repo for binaries of one of our software which doesn't need installation, which gets directly deployed to our customers. Each customer is something like a branch or tag and some of the customers are grouped for some reason, sharing the same parent directories, share the same access rights etc. Some of my repos contain web applications installed on different servers, again directly deployed as working copies and again different installations on the same server are grouped together under the same server name. I have only little experience with git almost a year ago, but what I remember is that git does support tags and branches and neither of those could be structured in any way, git only allowed one level for tags and branches. That's especially interesting because I've read a lot of times that git is better with a large number of branches and tags than Subversion, because branches and tags are easier to handle in git. And now please explain why it is better to be unable to structure branches and tags in a way one likes or a project needs? And if git is suboptimal in this case as well and other SCMs allow hierarchical branches and tags, like Subversion, why should this hierarchy be anything other or separate than what Subversion provides with its files and directories? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow