Hi Paolo, >> - There are problems with this approach. In the Changes view, when you >> select a revision that doesn't have results for the currently selected >> branch, nothing would be displayed. > > You're referring to an SVN context, right? Otherwise I can't make sense of it.
The opposite. For subversion, revisions mark the whole repository, so a revision could have results for both trunk and a branch. That is not the case in mercurial. Regarding my explanation, I understand it is a bit difficult to visualize this UI issues without images. >> You would need to blindly search >> for your results. An option is to always display all branches for a >> revision, but sometimes a revision will contain results for a branch, >> sometimes for others. > Outside of the SVN context, I'm not sure I get what you mean here, > because revisions in different branches are not necessarily > comparable. Same as above. So the differences between version control systems really suggest that you cannot add a branch dimension to a revision. More like a result is not only associated to a project, revision, and executable, but also to a branch... 2011/1/21 Paolo Giarrusso <[email protected]>: > Hi Miquel! > >> I would gladly hear other ideas. > Here are my two cents! > > On Fri, Jan 21, 2011 at 08:49, Miquel Torres <[email protected]> wrote: >> So one idea would be: >> - Every revision has a branch associated to it (a problem though is >> that subversion has the same revision number for all branches, while >> mercurial and git not) > This suggests (to me) that a revision would be associated to a > specific branch, but then I don't get expressions like "all the > branches for a revision". Maybe you mean that you would replace > revisions with pairs (Revision, Branch)? > [...] >> - There are problems with this approach. In the Changes view, when you >> select a revision that doesn't have results for the currently selected >> branch, nothing would be displayed. > > You're referring to an SVN context, right? Otherwise I can't make sense of it. > > I guess you can use, on other branches, the "closest" revision > available, after defining a linear order on revisions across branches. > You have that order in SVN; since you don't have that in Git, why > don't you just use the _date_ of a revision as the ordering key? > [For the data structures to implement this, I've seen even seen > interfaces to tree-based dictionaries allowing navigating to the > key-predecessor and key-successor, which might be especially handy > here (such as NavigableMap in Java, dunno about Python).] > Of course, that's suitable just as default, so you need to be able to > navigate between revisions independently for each branch. > > Please note that with complex merge histories, using the date does not > necessarily make sense - so that at least Git tools provide many > linearization algorithms. The problem is that a commit might be made > on a certain date in some repository, but be merged on mainline much > later, especially when many developers are not committers themselves; > one solution is to consider only revisions which were committed > directly on the branch or merged shortly after. > I also would believe this use case does not appear for PyPy. > See help about git log --topo-order and --date-order (such docs used > to be more complete, though). > >> You would need to blindly search >> for your results. An option is to always display all branches for a >> revision, but sometimes a revision will contain results for a branch, >> sometimes for others. > Outside of the SVN context, I'm not sure I get what you mean here, > because revisions in different branches are not necessarily > comparable. > -- > Paolo Giarrusso - Ph.D. Student > http://www.informatik.uni-marburg.de/~pgiarrusso/ > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
