* delete dead feature branches? @ 2009-09-25 15:28 Jason Merrill 2009-09-25 15:48 ` Ian Lance Taylor 2009-09-25 18:42 ` Joseph S. Myers 0 siblings, 2 replies; 23+ messages in thread From: Jason Merrill @ 2009-09-25 15:28 UTC (permalink / raw) To: gcc The SVN book (http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html) suggests deleting feature branches that have been merged into the trunk; I think this would help to reduce the clutter in the branches directory and avoid confusion with people expecting to find ongoing development on abandoned branches. The branches would continue to exist in the revision history, just not not in the current revision. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 15:28 delete dead feature branches? Jason Merrill @ 2009-09-25 15:48 ` Ian Lance Taylor 2009-09-25 18:42 ` Joseph S. Myers 1 sibling, 0 replies; 23+ messages in thread From: Ian Lance Taylor @ 2009-09-25 15:48 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc Jason Merrill <jason@redhat.com> writes: > The SVN book > (http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html) > suggests deleting feature branches that have been merged into the > trunk; I think this would help to reduce the clutter in the branches > directory and avoid confusion with people expecting to find ongoing > development on abandoned branches. The branches would continue to > exist in the revision history, just not not in the current revision. Go for it. Ian ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 15:28 delete dead feature branches? Jason Merrill 2009-09-25 15:48 ` Ian Lance Taylor @ 2009-09-25 18:42 ` Joseph S. Myers 2009-09-25 19:00 ` Jason Merrill 2009-10-11 22:51 ` Ben Elliston 1 sibling, 2 replies; 23+ messages in thread From: Joseph S. Myers @ 2009-09-25 18:42 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc On Fri, 25 Sep 2009, Jason Merrill wrote: > The SVN book > (http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html) > suggests deleting feature branches that have been merged into the trunk; I > think this would help to reduce the clutter in the branches directory and > avoid confusion with people expecting to find ongoing development on abandoned > branches. The branches would continue to exist in the revision history, just > not not in the current revision. Do we believe any future conversion to another version control system (that might have a more structured notion of what is a branch than it simply being a directory used in a certain way) would continue to make the history of such branches readily available? (This is more something to make sure of in the course of such a conversion, that this history is kept, but we might wish to avoid making such a conversion unnecessarily hard.) We also have branches/dead/, and a feature branch may be dead for reasons other than having been merged into trunk (for example, it may have been replaced by another branch without all changes being merged into trunk). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 18:42 ` Joseph S. Myers @ 2009-09-25 19:00 ` Jason Merrill 2009-09-25 19:21 ` Gabriel Dos Reis 2009-10-11 22:51 ` Ben Elliston 1 sibling, 1 reply; 23+ messages in thread From: Jason Merrill @ 2009-09-25 19:00 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc On 09/25/2009 12:55 PM, Joseph S. Myers wrote: > Do we believe any future conversion to another version control system > (that might have a more structured notion of what is a branch than it > simply being a directory used in a certain way) would continue to make the > history of such branches readily available? (This is more something to > make sure of in the course of such a conversion, that this history is > kept, but we might wish to avoid making such a conversion unnecessarily > hard.) git-svn seems to look at deleted branches during the import. > We also have branches/dead/, Does that have advantages over just deleting them? > and a feature branch may be dead for reasons > other than having been merged into trunk (for example, it may have been > replaced by another branch without all changes being merged into trunk). My inclination would be to delete branches like that as well. I would distinguish between branches that have been replaced by another branch or trunk, which I would delete, and branches that haven't had any development on them in a while, but haven't been merged anywhere either, which I would retain. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 19:00 ` Jason Merrill @ 2009-09-25 19:21 ` Gabriel Dos Reis 2009-09-25 19:24 ` Richard Guenther 0 siblings, 1 reply; 23+ messages in thread From: Gabriel Dos Reis @ 2009-09-25 19:21 UTC (permalink / raw) To: Jason Merrill; +Cc: Joseph S. Myers, gcc On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill <jason@redhat.com> wrote: > >> other than having been merged into trunk (for example, it may have been >> replaced by another branch without all changes being merged into trunk). > > My inclination would be to delete branches like that as well. that sounds a sensible thing to do. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 19:21 ` Gabriel Dos Reis @ 2009-09-25 19:24 ` Richard Guenther 2009-09-25 23:45 ` Joseph S. Myers 0 siblings, 1 reply; 23+ messages in thread From: Richard Guenther @ 2009-09-25 19:24 UTC (permalink / raw) To: gdr; +Cc: Jason Merrill, Joseph S. Myers, gcc On Fri, Sep 25, 2009 at 9:14 PM, Gabriel Dos Reis <dosreis@gmail.com> wrote: > On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill <jason@redhat.com> wrote: >> >>> other than having been merged into trunk (for example, it may have been >>> replaced by another branch without all changes being merged into trunk). >> >> My inclination would be to delete branches like that as well. > > that sounds a sensible thing to do. Can you still see deleted branches when you list svn/gcc/branches? If not we should somewhere note down the last undeleted revision of a branch, otherwise you'd have to random guess revisions for checking them out, no? Richard. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 19:24 ` Richard Guenther @ 2009-09-25 23:45 ` Joseph S. Myers 2009-09-26 4:54 ` Source control features (Was: Re: delete dead feature branches?) Joern Rennecke 2009-10-12 14:24 ` delete dead feature branches? Paolo Bonzini 0 siblings, 2 replies; 23+ messages in thread From: Joseph S. Myers @ 2009-09-25 23:45 UTC (permalink / raw) To: Richard Guenther; +Cc: gdr, Jason Merrill, gcc On Fri, 25 Sep 2009, Richard Guenther wrote: > On Fri, Sep 25, 2009 at 9:14 PM, Gabriel Dos Reis <dosreis@gmail.com> wrote: > > On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill <jason@redhat.com> wrote: > >> > >>> other than having been merged into trunk (for example, it may have been > >>> replaced by another branch without all changes being merged into trunk). > >> > >> My inclination would be to delete branches like that as well. > > > > that sounds a sensible thing to do. > > Can you still see deleted branches when you list svn/gcc/branches? If not > we should somewhere note down the last undeleted revision of a branch, > otherwise you'd have to random guess revisions for checking them out, no? Viewing deleted files and their history (and for SVN deleted branches are just a special case of deleted files) is something SVN is bad at since you do need to work out the last revision the file was present first. I hope that any version control system we change to will make it easy again to see the history of a deleted file (including one in a deleted directory, or on a deleted branch) if you know its name but not exactly when it was deleted. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Source control features (Was: Re: delete dead feature branches?) 2009-09-25 23:45 ` Joseph S. Myers @ 2009-09-26 4:54 ` Joern Rennecke 2009-10-12 14:24 ` delete dead feature branches? Paolo Bonzini 1 sibling, 0 replies; 23+ messages in thread From: Joern Rennecke @ 2009-09-26 4:54 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Richard Guenther, gdr, Jason Merrill, gcc Quoting "Joseph S. Myers" <joseph@codesourcery.com>: > Viewing deleted files and their history (and for SVN deleted branches are > just a special case of deleted files) is something SVN is bad at since you > do need to work out the last revision the file was present first. I hope > that any version control system we change to will make it easy again to > see the history of a deleted file (including one in a deleted directory, > or on a deleted branch) if you know its name but not exactly when it was > deleted. While we are on the subject of SVNs shortcomings, I'd like to point out another one: finding deleted lines. When I had shell account access to the RCS / CVS server, I could do a straightforward regexp search on the RCS *,v file to search the entire history of a file, and look at the vincinity of the match to understand context and find the last revision the match appeared in. Although this was not an official interface of CVS / RCS, it was very useful at times. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 23:45 ` Joseph S. Myers 2009-09-26 4:54 ` Source control features (Was: Re: delete dead feature branches?) Joern Rennecke @ 2009-10-12 14:24 ` Paolo Bonzini 2009-10-12 21:17 ` Jason Merrill 1 sibling, 1 reply; 23+ messages in thread From: Paolo Bonzini @ 2009-10-12 14:24 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Richard Guenther, gdr, Jason Merrill, gcc On 09/25/2009 09:35 PM, Joseph S. Myers wrote: > Viewing deleted files and their history (and for SVN deleted branches are > just a special case of deleted files) is something SVN is bad at since you > do need to work out the last revision the file was present first. Yep. Anyone deleting dead branches should add a link to the last "live" version in branches.html. It seems easier to me to move them under branches/dead, and possibly create branches/merged. Paolo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 14:24 ` delete dead feature branches? Paolo Bonzini @ 2009-10-12 21:17 ` Jason Merrill 2009-10-12 21:21 ` Andrew Pinski 2009-10-13 1:19 ` Michael Matz 0 siblings, 2 replies; 23+ messages in thread From: Jason Merrill @ 2009-10-12 21:17 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Joseph S. Myers, Richard Guenther, gdr, gcc On 10/12/2009 10:22 AM, Paolo Bonzini wrote: > Yep. Anyone deleting dead branches should add a link to the last "live" > version in branches.html. It seems easier to me to move them under > branches/dead, and possibly create branches/merged. Multiple directory levels under branches/ confuse git-svn; it thinks "dead" is a single branch. I'd rather not expand on that usage. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 21:17 ` Jason Merrill @ 2009-10-12 21:21 ` Andrew Pinski 2009-10-12 22:18 ` Jason Merrill 2009-10-13 1:19 ` Michael Matz 1 sibling, 1 reply; 23+ messages in thread From: Andrew Pinski @ 2009-10-12 21:21 UTC (permalink / raw) To: Jason Merrill; +Cc: Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Mon, Oct 12, 2009 at 2:15 PM, Jason Merrill <jason@redhat.com> wrote: > On 10/12/2009 10:22 AM, Paolo Bonzini wrote: >> >> Yep. Anyone deleting dead branches should add a link to the last "live" >> version in branches.html. It seems easier to me to move them under >> branches/dead, and possibly create branches/merged. > > Multiple directory levels under branches/ confuse git-svn; it thinks "dead" > is a single branch. I'd rather not expand on that usage. That seems like a huge bug in git-svn because we already use multiple directory levels under branches. Hint ibm and redhat and debain. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 21:21 ` Andrew Pinski @ 2009-10-12 22:18 ` Jason Merrill 2009-10-14 2:06 ` Daniel Berlin 2009-10-14 6:33 ` Alexandre Oliva 0 siblings, 2 replies; 23+ messages in thread From: Jason Merrill @ 2009-10-12 22:18 UTC (permalink / raw) To: Andrew Pinski; +Cc: Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On 10/12/2009 05:17 PM, Andrew Pinski wrote: > That seems like a huge bug in git-svn because we already use multiple > directory levels under branches. Hint ibm and redhat and debain. Yep, that's why I said "expand". I've thought about fixing that aspect of git-svn, but I'm not sure how it would tell the difference between a branch directory and a directory of branches given that SVN basically models a filesystem. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 22:18 ` Jason Merrill @ 2009-10-14 2:06 ` Daniel Berlin 2009-10-14 3:16 ` Joern Rennecke 2009-10-14 6:33 ` Alexandre Oliva 1 sibling, 1 reply; 23+ messages in thread From: Daniel Berlin @ 2009-10-14 2:06 UTC (permalink / raw) To: Jason Merrill Cc: Andrew Pinski, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Mon, Oct 12, 2009 at 5:20 PM, Jason Merrill <jason@redhat.com> wrote: > On 10/12/2009 05:17 PM, Andrew Pinski wrote: >> >> That seems like a huge bug in git-svn because we already use multiple >> directory levels under branches. Hint ibm and redhat and debain. > > Yep, that's why I said "expand". I've thought about fixing that aspect of > git-svn, but I'm not sure how it would tell the difference between a branch > directory and a directory of branches given that SVN basically models a > filesystem. > Branches always start with a copy of a directory somewhere else, at least in the gcc repo. Further, at least in the gcc repo, all branches start with a copy of a directory from branches or from trunk. So, it's fairly easy to detect branches. > Jason > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-14 2:06 ` Daniel Berlin @ 2009-10-14 3:16 ` Joern Rennecke 0 siblings, 0 replies; 23+ messages in thread From: Joern Rennecke @ 2009-10-14 3:16 UTC (permalink / raw) To: Daniel Berlin Cc: Jason Merrill, Andrew Pinski, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc Quoting Daniel Berlin <dberlin@dberlin.org>: > Branches always start with a copy of a directory somewhere else, at > least in the gcc repo. > Further, at least in the gcc repo, all branches start with a copy of a > directory from branches or from trunk. > So, it's fairly easy to detect branches. I disagree. In svn, you can legitimately rename / move around directories of branches. This will be implemented as copying the directory and then deleting the original. That's not trivial to distinguish from cutting a branch from another branch, and then deleting the latter. What about giving the conversion tool a list of branch and tag directories? I would think that conversions are few and far between, and the effort of compiling the list will be small compared to the time lost when the conversion gets things wrong. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 22:18 ` Jason Merrill 2009-10-14 2:06 ` Daniel Berlin @ 2009-10-14 6:33 ` Alexandre Oliva 1 sibling, 0 replies; 23+ messages in thread From: Alexandre Oliva @ 2009-10-14 6:33 UTC (permalink / raw) To: Jason Merrill Cc: Andrew Pinski, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Oct 12, 2009, Jason Merrill <jason@redhat.com> wrote: > On 10/12/2009 05:17 PM, Andrew Pinski wrote: >> That seems like a huge bug in git-svn because we already use multiple >> directory levels under branches. Hint ibm and redhat and debain. > Yep, that's why I said "expand". I've thought about fixing that > aspect of git-svn, but I'm not sure how it would tell the difference > between a branch directory and a directory of branches given that SVN > basically models a filesystem. I don't think it can tell the difference. AFAICT, we have to tell it ourselves. For the past several weeks, I've been working on creating another git repository to address this, using the following configuration file: [core] repositoryformatversion = 0 filemode = true bare = true logallrefupdates = true [svn-remote "svn"] rewriteRoot = svn+ssh://gcc.gnu.org/svn/gcc # url = svn+ssh://aoliva@gcc.gnu.org./svn/gcc url = file:///l/tmp/build/gcc/gccrepo fetch = trunk:refs/remotes/trunk branches = branches/ARM/*:refs/remotes/branches/ARM/* fetch = branches/ARM:refs/remotes/dirs/branches/ARM branches = branches/apple/*:refs/remotes/branches/apple/* fetch = branches/apple:refs/remotes/dirs/branches/apple branches = branches/csl/*:refs/remotes/branches/csl/* fetch = branches/csl:refs/remotes/dirs/branches/csl branches = branches/dead/*:refs/remotes/branches/dead/* fetch = branches/dead:refs/remotes/dirs/branches/dead branches = branches/gcj/*:refs/remotes/branches/gcj/* fetch = branches/gcj:refs/remotes/dirs/branches/gcj branches = branches/ibm/*:refs/remotes/branches/ibm/* fetch = branches/ibm:refs/remotes/dirs/branches/ibm branches = branches/ix86/*:refs/remotes/branches/ix86/* fetch = branches/ix86:refs/remotes/dirs/branches/ix86 branches = branches/redhat/*:refs/remotes/branches/redhat/* fetch = branches/redhat:refs/remotes/dirs/branches/redhat branches = branches/st/*:refs/remotes/branches/st/* fetch = branches/st:refs/remotes/dirs/branches/st branches = branches/suse/*:refs/remotes/branches/suse/* fetch = branches/suse:refs/remotes/dirs/branches/suse branches = branches/ubuntu/*:refs/remotes/barnches/ubuntu/* fetch = branches/ubuntu:refs/remotes/dirs/branches/ubuntu branches = branches/*:refs/remotes/branches/* fetch = branches:refs/remotes/dirs/branches/root tags = tags/apple/*:refs/remotes/tags/apple/* fetch = tags/apple:refs/remotes/tags/dirs/apple tags = tags/csl/arm/*:refs/remotes/tags/csl/arm/* fetch = tags/csl/arm:refs/remotes/tags/dirs/csl/arm tags = tags/csl/coldfire/*:refs/remotes/tags/csl/coldfire/* fetch = tags/csl/coldfire:refs/remotes/tags/dirs/csl/coldfire tags = tags/csl/morpho/*:refs/remotes/tags/csl/morpho/* fetch = tags/csl/morpho:refs/remotes/tags/dirs/csl/morpho tags = tags/csl/renesas/*:refs/remotes/tags/csl/renesas/* fetch = tags/csl/renesas:refs/remotes/tags/dirs/csl/renesas tags = tags/csl/sourcerygxx/*:refs/remotes/tags/csl/sourcerygxx/* fetch = tags/csl/sourcerygxx:refs/remotes/tags/dirs/csl/sourcerygxx tags = tags/csl/wrs-linux/*:refs/remotes/tags/csl/wrs-linux/* fetch = tags/csl/wrs-linux:refs/remotes/tags/dirs/csl/wrs-linux tags = tags/csl/*:refs/remotes/tags/csl/others/* fetch = tags/csl:refs/remotes/tags/dirs/csl/root tags = tags/ix86/*:refs/remotes/tags/ix86/* fetch = tags/ix86:refs/remotes/tags/dirs/ix86 tags = branches/st/tags/*:refs/remotes/tags/st/* fetch = branches/st/tags:refs/remotes/tags/dirs/st tags = tags/redhat/*:refs/remotes/tags/redhat/* fetch = tags/redhat:refs/remotes/tags/dirs/redhat tags = tags/ubuntu/*:refs/remotes/tags/ubuntu/* fetch = tags/ubuntu:refs/remotes/tags/dirs/ubuntu tags = tags/*:refs/remotes/tags/* fetch = tags:refs/remotes/tags/dirs/root fetch = :refs/remotes/dirs/root This preserves the complete svn history, although at times in a somewhat convoluted way. Because git-svn refuses to treat say branches/redhat as a branch if branches/redhat/gcc-4_4-branch exists, and vice-versa, I keep track of directories that do not correspond to a branch or tag of the entire tree in directories that contain “dirs” as one of the pathname components. I wish the GCC git repository could integrate at least some of these fetch configurations, so that branches in subdirs can be handled as proper branches. All this said, unless we want to expand on the need for ugly git-svn configurations as above, we'd be better off avoiding more sub-dirs. The alternative would have been to adopt a uniform depth for all branches and tags, but it's too late for that now. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-12 21:17 ` Jason Merrill 2009-10-12 21:21 ` Andrew Pinski @ 2009-10-13 1:19 ` Michael Matz 2009-10-13 13:50 ` Jason Merrill 2009-10-14 1:37 ` Ben Elliston 1 sibling, 2 replies; 23+ messages in thread From: Michael Matz @ 2009-10-13 1:19 UTC (permalink / raw) To: Jason Merrill; +Cc: Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc Hi, On Mon, 12 Oct 2009, Jason Merrill wrote: > On 10/12/2009 10:22 AM, Paolo Bonzini wrote: > > Yep. Anyone deleting dead branches should add a link to the last "live" > > version in branches.html. It seems easier to me to move them under > > branches/dead, and possibly create branches/merged. > > Multiple directory levels under branches/ confuse git-svn; it thinks "dead" is > a single branch. I'd rather not expand on that usage. I don't think we should necessarily limit ourself by bugs in foreign tools if it reduces useful information. What about a new top-level directory dead-branches/, not under branches/ but parallel to it? Should be easy to exempt from git-svn handling, shouldn't it? Ciao, Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-13 1:19 ` Michael Matz @ 2009-10-13 13:50 ` Jason Merrill 2009-10-14 1:37 ` Ben Elliston 1 sibling, 0 replies; 23+ messages in thread From: Jason Merrill @ 2009-10-13 13:50 UTC (permalink / raw) To: Michael Matz; +Cc: Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On 10/12/2009 09:05 PM, Michael Matz wrote: > I don't think we should necessarily limit ourself by bugs in foreign tools > if it reduces useful information. What about a new top-level directory > dead-branches/, not under branches/ but parallel to it? Should be easy to > exempt from git-svn handling, shouldn't it? Yes, git-svn would ignore such a directory. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-13 1:19 ` Michael Matz 2009-10-13 13:50 ` Jason Merrill @ 2009-10-14 1:37 ` Ben Elliston 2009-10-14 5:55 ` Jason Merrill ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Ben Elliston @ 2009-10-14 1:37 UTC (permalink / raw) To: Michael Matz Cc: Jason Merrill, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Tue, 2009-10-13 at 03:05 +0200, Michael Matz wrote: > I don't think we should necessarily limit ourself by bugs in foreign tools > if it reduces useful information. What about a new top-level directory > dead-branches/, not under branches/ but parallel to it? Should be easy to > exempt from git-svn handling, shouldn't it? I found that svn log works well if you do this: svn log svn+ssh://bje@gcc.gnu.org/svn/gcc | less The important thing is to make sure that the log message carefully describes the name of the branch when it is deleted, so that one can search the log output to find it. I deleted a personal branch from 5 years ago and have added the revision number of the delete commit to the branch description in svn.html. Would these two conventions suffice? Ben ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-14 1:37 ` Ben Elliston @ 2009-10-14 5:55 ` Jason Merrill 2009-10-14 9:36 ` Michael Matz 2009-10-25 18:32 ` Gerald Pfeifer 2 siblings, 0 replies; 23+ messages in thread From: Jason Merrill @ 2009-10-14 5:55 UTC (permalink / raw) To: Ben Elliston Cc: Michael Matz, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On 10/13/2009 08:50 PM, Ben Elliston wrote: > I found that svn log works well if you do this: > > svn log svn+ssh://bje@gcc.gnu.org/svn/gcc | less Which in recent versions of svn can also be written svn log ^/ |less if you're in an SVN working directory. Jason ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-14 1:37 ` Ben Elliston 2009-10-14 5:55 ` Jason Merrill @ 2009-10-14 9:36 ` Michael Matz 2009-10-15 8:17 ` Ben Elliston 2009-10-25 18:32 ` Gerald Pfeifer 2 siblings, 1 reply; 23+ messages in thread From: Michael Matz @ 2009-10-14 9:36 UTC (permalink / raw) To: Ben Elliston Cc: Jason Merrill, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc Hi, On Wed, 14 Oct 2009, Ben Elliston wrote: > I deleted a personal branch from 5 years ago and have added the revision > number of the delete commit to the branch description in svn.html. > > Would these two conventions suffice? Well, I'm always of the opinion that it's better to have some technical solution to ensure something (in this case to not loose track of old branches) instead of relying on conventions, unless the technical solutions are cumbersome in some way. So, why not just move them to dead-branches now, and be done with it? Ciao, Michael. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-14 9:36 ` Michael Matz @ 2009-10-15 8:17 ` Ben Elliston 0 siblings, 0 replies; 23+ messages in thread From: Ben Elliston @ 2009-10-15 8:17 UTC (permalink / raw) To: Michael Matz Cc: Jason Merrill, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Wed, 2009-10-14 at 08:33 +0200, Michael Matz wrote: > So, why not just move them to dead-branches now, and be done with it? OK, your argument has convinced me. :-) Cheers, Ben ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-10-14 1:37 ` Ben Elliston 2009-10-14 5:55 ` Jason Merrill 2009-10-14 9:36 ` Michael Matz @ 2009-10-25 18:32 ` Gerald Pfeifer 2 siblings, 0 replies; 23+ messages in thread From: Gerald Pfeifer @ 2009-10-25 18:32 UTC (permalink / raw) To: Ben Elliston Cc: Michael Matz, Jason Merrill, Paolo Bonzini, Joseph S. Myers, Richard Guenther, gdr, gcc On Wed, 14 Oct 2009, Ben Elliston wrote: > I deleted a personal branch from 5 years ago and have added the revision > number of the delete commit to the branch description in svn.html. > > Would these two conventions suffice? Would it make sense to document the outcome of this conversation in svn.html? Gerald ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: delete dead feature branches? 2009-09-25 18:42 ` Joseph S. Myers 2009-09-25 19:00 ` Jason Merrill @ 2009-10-11 22:51 ` Ben Elliston 1 sibling, 0 replies; 23+ messages in thread From: Ben Elliston @ 2009-10-11 22:51 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Jason Merrill, gcc On Fri, 2009-09-25 at 16:55 +0000, Joseph S. Myers wrote: > Do we believe any future conversion to another version control system > (that might have a more structured notion of what is a branch than it > simply being a directory used in a certain way) would continue to make the > history of such branches readily available? If that happens to be true with some future version control system, couldn't we restore the deleted branches before running whatever conversion tool exists? Ben -- Ben Elliston <bje@au.ibm.com> Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-10-25 14:54 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-25 15:28 delete dead feature branches? Jason Merrill 2009-09-25 15:48 ` Ian Lance Taylor 2009-09-25 18:42 ` Joseph S. Myers 2009-09-25 19:00 ` Jason Merrill 2009-09-25 19:21 ` Gabriel Dos Reis 2009-09-25 19:24 ` Richard Guenther 2009-09-25 23:45 ` Joseph S. Myers 2009-09-26 4:54 ` Source control features (Was: Re: delete dead feature branches?) Joern Rennecke 2009-10-12 14:24 ` delete dead feature branches? Paolo Bonzini 2009-10-12 21:17 ` Jason Merrill 2009-10-12 21:21 ` Andrew Pinski 2009-10-12 22:18 ` Jason Merrill 2009-10-14 2:06 ` Daniel Berlin 2009-10-14 3:16 ` Joern Rennecke 2009-10-14 6:33 ` Alexandre Oliva 2009-10-13 1:19 ` Michael Matz 2009-10-13 13:50 ` Jason Merrill 2009-10-14 1:37 ` Ben Elliston 2009-10-14 5:55 ` Jason Merrill 2009-10-14 9:36 ` Michael Matz 2009-10-15 8:17 ` Ben Elliston 2009-10-25 18:32 ` Gerald Pfeifer 2009-10-11 22:51 ` Ben Elliston
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).