Re: Revision control advice
On Wed, 21 Dec 2011, Chris Hill wrote: I'm looking to set up some sort of revision control system at work. Thank you to everyone who replied. Based on what I've found out, I think I will be setting up git on a test server so I can get familiar with it. Thanks again, and a happy $HOLIDAY to all. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging / ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On Sat, Dec 24, 2011 at 9:22 AM, Chris Hill ch...@monochrome.org wrote: On Wed, 21 Dec 2011, Chris Hill wrote: I'm looking to set up some sort of revision control system at work. Thank you to everyone who replied. Based on what I've found out, I think I will be setting up git on a test server so I can get familiar with it. Thanks again, and a happy $HOLIDAY to all. I find this article about setting up git on FreeBSD to be helpful: http://forums.freebsd.org/showthread.php?t=10810 Happy Holidays, Waitman Gobble San José California USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On 22/12/2011 04:53, Rob Byrnes wrote: Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. git or mercurial - best choices For what reasons? svn vs git vs mercurial svn has the model of a central repository that everything has to communicate with. This can be attractive in a commercial environment as it implies a degree of central control over all of the project source code. git is much more a peer-to-peer system. This fits with a disparate group of projects all proceeding pretty much independently. There's also a potential advantage if all your developers are not at the same location and will not necessarily have access to central office systems. mercurial unfortunately I'm not that familiar with, but it uses a distributed model like git. Other criteria, like windows support, are not anything I have much experience of, but by all accounts svn and git are pretty well served. Any of these will serve you well, and unless you have a killer requirement that makes it obvious which to choose from, then you risk spending a lot of effort trying to minutely analyse the niggling details of each contender to no ultimate benefit. At some point you're going to be better off simply by tossing a coin to choose. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Revision control advice
On Wed, Dec 21, 2011 at 08:24:01PM -0700, ss griffon wrote: On Wed, Dec 21, 2011 at 7:49 PM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 12/22/11 11:37, Chris Hill wrote: Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. I'd suggest subversion. It allows individual files to be versioned, you can setup a webdav interface, and there are other tools that can help maintain it. Forget the individual repositories. Setup a single repository and have directories for each project. in each directory you can then setup trunk, branches, whatever, as per best practices in the Book. Designate a person or two to administer, and use directory level auth, or another alternative I haven't thought of. My 2c's anyway. HTH Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. I'll 3rd the choice of Subversion. It's quite easy to setup and use. There's also the book online: http://svnbook.red-bean.com/en/1.7/index.html for you to read at your pleasure and which you can also point your users to. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html pgpMEnRYeumWx.pgp Description: PGP signature
Re: Revision control advice
On 22/12/2011, at 20:06, Matthew Seaman wrote: On 22/12/2011 04:53, Rob Byrnes wrote: Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. git or mercurial - best choices For what reasons? svn vs git vs mercurial svn has the model of a central repository that everything has to communicate with. This can be attractive in a commercial environment as it implies a degree of central control over all of the project source code. git is much more a peer-to-peer system. This fits with a disparate group of projects all proceeding pretty much independently. There's also a potential advantage if all your developers are not at the same location and will not necessarily have access to central office systems. mercurial unfortunately I'm not that familiar with, but it uses a distributed model like git. I would advise staying away from mercurial (aka hg). It has a lot of issues with corruption of repositories. Git does the same and is a lot more mature and stable. Other criteria, like windows support, are not anything I have much experience of, but by all accounts svn and git are pretty well served. Again, git wins here. It has good support on windows, as well as with graphical tools on windows. You can use git like SVN if you push to the master after every commit though. I also have found git's support for merging to be a lot better. Additionally it stores branches and tags as metadata on commits rather than svn's dumb tag / branch system where you just copy the full repo to the side. Git does take a bit longer to get your head around how some of the tools work, but once you learn it, it really pays off. Sincerely, William Brown Research Teaching, Technology Services The University of Adelaide, AUSTRALIA 5005 CRICOS Provider Number 00123M - IMPORTANT: This message may contain confidential or legally privileged information. If you think it was sent to you by mistake, please delete all copies and advise the sender. For the purposes of the SPAM Act 2003, this email is authorised by The University of Adelaide. pgp.mit.edu PGP.sig Description: This is a digitally signed message part
Re: [freebsd-questions] Revision control advice
On 22/12/2011 22:53, William Brown wrote: Again, git wins here. It has good support on windows, as well as with graphical tools on windows. Is there a git equivalent of TortoiseSVN then? That's the best VC integration I've seen on any platform... One small but cosmetic thing with git vs svn: you won't get meaningful automatic revision numbers with git, unless you enjoy memorizing long strings of hex. Howie (warming up to git, but uses svn at the moment) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
Absolutely go distributed vcs over centralized. Keeping code always under version control, even when local in your sandbox, is extremely powerful. And since a distributed vcs can be used as a centralized vcs, there's really no technical reason to use a centralized vcs. - Original Message - From: William Brown william.e.br...@adelaide.edu.au I would advise staying away from mercurial (aka hg). It has a lot of issues with corruption of repositories. Git does the same and is a lot more mature and stable. Do you have any references re Mercurial repo corruption? I originally started using Mercurial a couple years ago because NetBeans had built-in support, but the command set is consistent and uniform, Bryan O'Sullivan's Definitive Guide is excellent, and TortoiseHg/HgWorkbench work flawlessly on Windows (I use the command line or the Natilus plugin when not on Windows). No argument that git has the mindshare, although arguably due more to github than git itself. Googling will show there are major projects using Mercurial as well. Dale - Transparency with Trust http://www.dalescott.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On Fri, Dec 23, 2011 at 09:23:22AM +1030, William Brown wrote: On 22/12/2011, at 20:06, Matthew Seaman wrote: svn vs git vs mercurial svn has the model of a central repository that everything has to communicate with. This can be attractive in a commercial environment as it implies a degree of central control over all of the project source code. git is much more a peer-to-peer system. This fits with a disparate group of projects all proceeding pretty much independently. There's also a potential advantage if all your developers are not at the same location and will not necessarily have access to central office systems. mercurial unfortunately I'm not that familiar with, but it uses a distributed model like git. I would advise staying away from mercurial (aka hg). It has a lot of issues with corruption of repositories. Git does the same and is a lot more mature and stable. Uh . . . what? Please provide a source for that claim. Other criteria, like windows support, are not anything I have much experience of, but by all accounts svn and git are pretty well served. Again, git wins here. It has good support on windows, as well as with graphical tools on windows. How does TortoiseGIT improve on TortoiseHG? I'm curious. You can use git like SVN if you push to the master after every commit though. I also have found git's support for merging to be a lot better. Additionally it stores branches and tags as metadata on commits rather than svn's dumb tag / branch system where you just copy the full repo to the side. For the vast majority of purposes, distributed VCSes like Fossil, Git, and Mercurial are quite superior to CVCSes such as Subversion. There are cases, however, where a truly centralized system is more appropriate. These are typically cases where division of labor is very starkly defined and a strong central control over everything needs to be maintained even when the people working out at the nodes of the system might be tempted to follow a different, ad-hoc process of their own. For those cases, something like Git (or Fossil or Mercurial) simply will not do. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Revision control advice
Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging / ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On 12/22/11 11:37, Chris Hill wrote: Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. I'd suggest subversion. It allows individual files to be versioned, you can setup a webdav interface, and there are other tools that can help maintain it. Forget the individual repositories. Setup a single repository and have directories for each project. in each directory you can then setup trunk, branches, whatever, as per best practices in the Book. Designate a person or two to administer, and use directory level auth, or another alternative I haven't thought of. My 2c's anyway. HTH ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On Wed, Dec 21, 2011 at 7:49 PM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 12/22/11 11:37, Chris Hill wrote: Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. I'd suggest subversion. It allows individual files to be versioned, you can setup a webdav interface, and there are other tools that can help maintain it. Forget the individual repositories. Setup a single repository and have directories for each project. in each directory you can then setup trunk, branches, whatever, as per best practices in the Book. Designate a person or two to administer, and use directory level auth, or another alternative I haven't thought of. My 2c's anyway. HTH ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On Wed, Dec 21, 2011 at 10:24 PM, ss griffon ssgriffonu...@gmail.com wrote: On Wed, Dec 21, 2011 at 7:49 PM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 12/22/11 11:37, Chris Hill wrote: Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. I'd suggest subversion. It allows individual files to be versioned, you can setup a webdav interface, and there are other tools that can help maintain it. Forget the individual repositories. Setup a single repository and have directories for each project. in each directory you can then setup trunk, branches, whatever, as per best practices in the Book. Designate a person or two to administer, and use directory level auth, or another alternative I haven't thought of. My 2c's anyway. HTH ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. git or mercurial - best choices ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Revision control advice
On 22 December 2011 15:07, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 21, 2011 at 10:24 PM, ss griffon ssgriffonu...@gmail.com wrote: On Wed, Dec 21, 2011 at 7:49 PM, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 12/22/11 11:37, Chris Hill wrote: Hello list, I apologize for this posting being not-much-on-topic, but my other resources have come to naught and I think you folks may have some experience in this area. I'm looking to set up some sort of revision control system at work. Simple enough, except that our situation is approximately the reverse of what most revision control systems are designed for. Unlike, e.g., FreeBSD kernel development, we have dozens or hundreds of small, rapid-fire projects that are created at the rate of 3 to 20 per month. They last a few days or a few months and are (usually) not developed afterward. Each project has one to three developers working on it, sometimes simultaneously. Usually it's one guy per project. Since my programmers are not necessarily UNIX-savvy, I'd like to deploy a web interface for them which will allow them to create new repositories (projects) as well as the normal checkin, checkout, etc. I want to set this up once, and from there on have the programmers deal with managing their own repos. And heaven forfend exposing them to the horrors of the shell. I've built a test server (9.0-RC3, amd64) for experimenting with this stuff. So far I've installed and played with: - fossil. I like the simplicity and light weight, but it doesn't seem to allow creation of new repos at all (let alone multiple ones) from the web interface, and the documentation is meager. I've pretty much given up on it. - subversion, which looks like the heavy hitter of RCSs, but it's not at all clear to me how to handle the multiple-project scenario. Still working on it. - git looks promising, but I have not installed it yet. If anyone can point me to a tool that might be suitable, I would be most grateful. I'd suggest subversion. It allows individual files to be versioned, you can setup a webdav interface, and there are other tools that can help maintain it. Forget the individual repositories. Setup a single repository and have directories for each project. in each directory you can then setup trunk, branches, whatever, as per best practices in the Book. Designate a person or two to administer, and use directory level auth, or another alternative I haven't thought of. My 2c's anyway. HTH ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Yeah I would second what Mr Rock says. Set up a single repo where folders can be used for projects. Since svn lets you checkout sub folders of a repo, each developer can check out the folder that corresponds to their project. Also, Tortoise svn is a very nice graphical utility that will allow your developers to manage there svn folders without even needing a web interface (most non unix people that I know like tortoise), so there is less maintenance for you :) Finally, kudos to moving towards using version control, its an important step for a software company. git or mercurial - best choices For what reasons? Rob -- Idiot : A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. (Ambrose Bierce - The Devils Dictionary) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
