Re: Your favorite version control software
Why do you prefer Subversion for the central repository and git for laptops? On Thu, 24 Mar 2011 17:14:39 -0400 Gregory Seidman gsslist+deb...@anthropohedron.net wrote: On Thu, Mar 24, 2011 at 03:33:44PM -0500, Jason Hsu wrote: What's your favorite version control software for software development? Subversion? Git? Something else? Subversion for the central repository, git (via git-svn) on the road (i.e. on laptops). -- Jason Hsu jhsu802...@jasonhsu.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110325113917.1aa78d13.jhsu802...@jasonhsu.com
Re: Your favorite version control software
On 2011-03-25 11:39:17 Jason Hsu wrote: Why do you prefer Subversion for the central repository and git for laptops? I can think of at least one reason: history. I haven't checked the default settings recently, but I seem to remember that git allowed forced pushes by default. This is great for your personal repositories, but not usually good for central repositories since a forced push can cause loss of history. Perhaps forced pushes are turned off when you create a shared / bare repository now; few central repositories are not created as one (or both) of these types. For laptops, or in any case where you may not have an active, reliable connection to the central repository, subversion just fails. You can't commit, branch, etc. All of the distributed VCSes support disconnected operations, even if they aren't the default. I prefer not-subversion for the central repository when developers are using a distributed VCS in practice. Subversion forces the history to be linearized, which often involves what git calls a rebase. Whatever your DVCS calls it, it makes new revisions/patches that whose relationship with the original ones are not tracked. Requiring this process before getting changes into the central repository can limits some of the effectiveness of the DVCS model. (Last I heard though, PostgreSQL forces this behavior even though they are using a DVCS to manage their central repository; there were enough developers that found a linear history easier to work with that it became policy.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Your favorite version control software
On Fri, Mar 25, 2011 at 5:59 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: On 2011-03-25 11:39:17 Jason Hsu wrote: Why do you prefer Subversion for the central repository and git for laptops? ... For laptops, or in any case where you may not have an active, reliable connection to the central repository, subversion just fails. You can't commit, branch, etc. All of the distributed VCSes support disconnected operations, even if they aren't the default. Even with LAN access to your SVN server, try a svn-bisect and then compare it to a git-bisect. There is no going back to SVN, once you understand the whole decentralized approach. git merge just works. I do agree that setting up the git server to refuse most delete operation take some time and tweaking. -- Mathieu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinngflfctsvtfgj6drwaook7ckzc_s4goxoh...@mail.gmail.com
Re: Your favorite version control software
On Fri, Mar 25, 2011 at 06:06:12PM +0100, Mathieu Malaterre wrote: On Fri, Mar 25, 2011 at 5:59 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: On 2011-03-25 11:39:17 Jason Hsu wrote: Why do you prefer Subversion for the central repository and git for laptops? ... For laptops, or in any case where you may not have an active, reliable connection to the central repository, subversion just fails. ?You can't commit, branch, etc. ?All of the distributed VCSes support disconnected operations, even if they aren't the default. Even with LAN access to your SVN server, try a svn-bisect and then compare it to a git-bisect. I'll agree that git-bisect is pretty awesome, but I can do it with git-svn when I need to. I also like git stash, and the line-by-line git add is pretty great when I need it. All of that is accessible via git-svn. There is no going back to SVN, once you understand the whole decentralized approach. git merge just works. I do agree that setting up the git server to refuse most delete operation take some time and tweaking. Either I don't get it or I won't drink the Kool-Aid. It's hard to say which. I understand the value of the decentralized approach for a decentralized project. That includes many open source projects. I believe that git is absolutely the best choice for the Linux kernel, for example. On the other hand, I *really* value a repository-wide, monotonically increasing version number. When I'm setting up source control for a project, I'll always go with subversion. Even if everyone working on the project uses git through git-svn and pulls changesets from one another, I want the central repository to have sequential revision numbers for commits. I want to be able to identify a revision number in a release that indicates all of the commits of which it is composed (i.e. any number less than that revision number). The whole GUID thing is fine for passing changes around, but it's meaningless for a release. So, yeah, git is great on the client side, but I want a central repository that is more oriented toward points in time than changesets. I can have both with git-svn. Mathieu --Greg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110325190024.ga10...@anthropohedron.net
Re: Your favorite version control software
On 2011-03-25 14:00:26 Gregory Seidman wrote: Either I don't get it or I won't drink the Kool-Aid. It's hard to say which. I understand the value of the decentralized approach for a decentralized project. That includes many open source projects. I believe that git is absolutely the best choice for the Linux kernel, for example. On the other hand, I *really* value a repository-wide, monotonically increasing version number. When I'm setting up source control for a project, I'll always go with subversion. Even if everyone working on the project uses git through git-svn and pulls changesets from one another, I want the central repository to have sequential revision numbers for commits. I want to be able to identify a revision number in a release that indicates all of the commits of which it is composed (i.e. any number less than that revision number). The whole GUID thing is fine for passing changes around, but it's meaningless for a release. git-describe provides friendlier descriptions of many trees. If you tag names sort well, then the output of git-describe sorts well for the majority of commits. Given a SHA and the repository, it is trivial to list all the commits that are ancestors of it. The output of git-describe provides enough context to usually get the whole SHA. Finally, if you just gotta have monotonically increasing numbers, it's relatively easy to trivial to have a hook on the central repository that generates tags automatically that use monotonically increasing numbers. The problem with monotonically increasing numbers is that they don't make sense for every commit in a non-linear history, because while there is a partial ordering of such commits, there is not a total ordering on such commits. The trick with the tags generated by a hook like I suggested is that it doesn't attempt to assign a number of *every* commit. Instead, it only assigns numbers to the synchronization points. Assuming the central repository is updated in a fast-forward manner (generally a good idea, and the default unless someone uses --force), then these synchronization points are a subset of commits in the non-linear history that DO have a total ordering. Bzr uses hashes/ids behind the scenes but generally recommends using something very close to numbers. Given a repository, each synchronization point is assigned a monotonically increasing number. Commits that aren't synchronization points, use a multiply-dotted syntax after the number that identifies the most recent synchronization point. It gives a very SVN like feel; the HEAD/trunk/master branch in the central repository is always at something that can be called revision N where n is a natural number. It's not entirely the same though, a local commit might be called 304 until you synchronize with someone else (like the central repository) and it starts being called 300.1.4. That only (I think) happens to private commits though; there's some guarantee that when you and someone else share a commit, it will have the same name for both of you. Hg and Mtn might also have solutions in this area. I tend to doubt Darcs does. So, yeah, git is great on the client side, but I want a central repository that is more oriented toward points in time than changesets. I can have both with git-svn. Git, Hg, and Mtn are not changeset oriented at all. Any diffs they present as part of a log are synthesized at that time. They (efficiently) store snapshots of the repository, and are not much concerned with how the repository got there. Darcs is very changeset oriented, it juggles patches not snapshots. It synthesizes the work tree as necessary, and understands patch dependencies enough to make that work tree deterministic. However, it doesn't fundamentally store states, be rather transitions between states. I think Bzr is similar to Git/Hg/Mtn, but I know it has some relationship with Arch so (like Arch) it might use changesets for some operations. So, with Git/Hg/Mtn a commit's hash/id *is* a unique identifier of a point in time, which is what you claim you are after. I tend to think that monotonically increasing natural numbers are a bit over-rated. However, if you want them you can get them without completely abandoning a non-linear history and some of the DVCS advantages that comes with. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Your favorite version control software
What's your favorite version control software for software development? Subversion? Git? Something else? -- Jason Hsu jhsu802...@jasonhsu.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324153344.7943ba95.jhsu802...@jasonhsu.com
Re: Your favorite version control software
On 2011-03-24 15:33:44 Jason Hsu wrote: What's your favorite version control software for software development? Subversion? Git? Something else? Git. However, I'm willing to work with anything distributed, I just know Git a lot better than Hg, Bzr, Mtn, or Darcs. If something non-distributed is entrenched in the project / workplace, I'll end up using Git with occasional synchronization with the inferior solution. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Your favorite version control software
On 24/03/11 20:33, Jason Hsu wrote: What's your favorite version control software for software development? Subversion? Git? Something else? I'd have to say git. I've been using version control systems since the early 1980's. I started developing a system to manage a product I was responsible for using a layer on top of SCCS (recursor to RCS, a precursor to CVS) trying to achieve exactly what git can now do. Of course I (and my team) didn't have the class to invent what Linus did. Our product what a base system in the telemetry area which then got modified for each individual project. I needed a system that could maintain version control whilst multiple project made changes around the core. Since those days, I always develop my own personal software using version control. I had long since understood the benefit of being able to know all the separate changes I had made in time. I had tried CVS, Bitkeeper and SVN but when Linus announced that he was suspending Kernel development whilst he got something together to replace Bitkeeper I decided to jump on the mailing list and find out what was going on. I didn't realise immediately what he had invented, but when I saw how distributed development and multiple branches - with merging - really worked I understood he had achieved what I had been trying to achieve all those years ago. I have been a fan ever since -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8bb41e.8020...@chandlerfamily.org.uk
Re: Your favorite version control software
On Thu, Mar 24, 2011 at 03:33:44PM -0500, Jason Hsu wrote: What's your favorite version control software for software development? Subversion? Git? Something else? Subversion for the central repository, git (via git-svn) on the road (i.e. on laptops). Jason Hsu jhsu802...@jasonhsu.com --Greg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324211438.gl7...@anthropohedron.net
Re: Your favorite version control software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 24/03/2011 21:40, Jason Hsu a écrit : What's your favorite version control software for software development? Subversion? Git? Something else? Mercurial - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNi8NJAAoJEK8zQvxDY4P9GBMH/2BaTqvPmpe2COrdGp2M9PWQ XwyJoKNHjP2iG3nsI74GkCju9zf3OAFVS3V0YLl4XNrr1LaDLJmdKVliCvqh4D8v 3cjv4RVUKDbeA3y6w6AxEO/bJA5e2oauf8QSY5LFo+C5/NewXPQhfL2EIjaJWkmZ lbNLdGMHkGzF7lm1a4qsJw7mtDKbO3ZtqUmNqKmiLsY3QZBDyBl5IFw0AvIJFqNA pf3BNQudb9eOkIwQdk0XZ1E25x2Dg09KbCXJP1i0Cj8bZ63OV74R21tRdVXV9j+Y qmy0t+Aqv+OCea85C5293H3IFuk+2MYSMytmYhk8d6tKBQvsuUHo39lC6/c2eJw= =uhR8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8bc349$0$20201$426a7...@news.free.fr
