Andrew Trick <atrick at apple.com> writes:> SVN revision numbers are central to my workflow. I use them to tag > results generated against various builds. I like those results sorted > by time and the chronology should be obvious,This means in the presence of branches, you want the ordering to be [branch A] build 1 [branch B] build 2 [branch A] build 3 [branch C] build 4 ? It seems to me that your solution works only if you have a very simple branch topology, where you can essentially consider branches in isolation. As soon as you consider non-trunk branches and merge commits to be important, the history is a DAG, and the problem is not that version numbers are not linear, but that the history itself is not. Of course, if you've used SVN extensively, you've been trained to think that history has to be somewhat linear, and perhaps even that the trunk branch is the only one needing QA attention. Migration from SVN to Git is hard because you have to change the mental model, not just command names and how revisions are named. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
On Jul 22, 2011, at 12:29 AM, Matthieu Moy wrote:> Andrew Trick <atrick at apple.com> writes: > >> SVN revision numbers are central to my workflow. I use them to tag >> results generated against various builds. I like those results sorted >> by time and the chronology should be obvious, > > This means in the presence of branches, you want the ordering to be > > [branch A] build 1 > [branch B] build 2 > [branch A] build 3 > [branch C] build 4 > > ? > > It seems to me that your solution works only if you have a very simple > branch topology, where you can essentially consider branches in > isolation. As soon as you consider non-trunk branches and merge commits > to be important, the history is a DAG, and the problem is not that > version numbers are not linear, but that the history itself is not. > > Of course, if you've used SVN extensively, you've been trained to think > that history has to be somewhat linear, and perhaps even that the trunk > branch is the only one needing QA attention. Migration from SVN to Git > is hard because you have to change the mental model, not just command > names and how revisions are named.You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git. My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*. I would like to think that git generation numbers are sufficient for this so we don't need to resort to timestamps or tags. Mercurial has local revision numbers for this purpose, which I thought were quite handy. Comments on that point are welcome. -Andy
On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote:>> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and how revisions are named. > > > You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git. > > My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*. > > I would like to think that git generation numbers are sufficient for this so we don't need to resort to timestamps or tags. Mercurial has local revision numbers for this purpose, which I thought were quite handy. Comments on that point are welcome.I completely agree. The "branch" I most care about is mainline, and losing the ability to say "fixed in r1234" (with some sort of monotonically increasing number) would be a tragic loss. -Chris
On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote:> On Jul 22, 2011, at 12:29 AM, Matthieu Moy wrote: > >> It seems to me that your solution works only if you have a very simple >> branch topology, where you can essentially consider branches in >> isolation. As soon as you consider non-trunk branches and merge commits >> to be important, the history is a DAG, and the problem is not that >> version numbers are not linear, but that the history itself is not. >> >> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and how revisions are named. > > > You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git. > > My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*. > > I would like to think that git generation numbers are sufficient for this so we don't need to resort to timestamps or tags. Mercurial has local revision numbers for this purpose, which I thought were quite handy. Comments on that point are welcome. >It would be hard for me to agree more with Andy's statement here. If we cannot solve this problem, git will be a big stumbling block for us. -bw
Andrew Trick <atrick at apple.com> writes:> I would like to think that git generation numbers are sufficient for > this so we don't need to resort to timestamps or tags.This works only if you have a "trunk branch", in the sense that you know exactly which sequence of commit is your "trunk". Git's designed is really not trunk-oriented, Linus has worked very hard against this concept while creating Git. The closest you can get is git log --first-parent the first parent being the one on which the guy who did the merge were before starting merging. But, suppose we have this: A---B <-- upstream version \ C <-- me Then, if I merge from upstream, I get A---B <--upstream \ \ C---D <-- me and D's first parent will be D. Then, if upstream merges from me, it fast-forwards and you get A---B \ \ C---D <-- me, upstream And B, which used to be a "mainline commit" is not one anymore. People who used to say "commit with generation number 1 in upstream" were refering to B, and the same sentence now refers to C. Each problem has a solution, so if upstream had merged from me with --no-ff, it would have got A---B---E <-- upstream \ \ / C---D <-- me With E having the same content as D, but different parents and commit message. It's not the workflow promoted by Git, but it works, if you make sure upstream always merges with --no-ff (that usually means making upstream an automated bot, and not human being using "git push").> Mercurial has local revision numbers for this purpose, which I thought > were quite handy. Comments on that point are welcome.The point with local revision numbers is that they are local. You can never say "bug has been fixed in revision 1234" without saying which repository you're talking about. Revision 1234 in my LLVM repository wouldn't necessarily be the same as the one used by a buildbot or some other developers. They're handy to work locally, but not as an identifier to use accross a team. I tend to find them more confusing than helpfull, but that's a matter of taste, and may be due to lack of experince with Mercurial ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/