Re: delete dead feature branches?
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.
Re: delete dead feature branches?
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
Re: delete dead feature branches?
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
Re: delete dead feature branches?
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://b...@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
Re: delete dead feature branches?
On Mon, Oct 12, 2009 at 5:20 PM, Jason Merrill ja...@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
Re: delete dead feature branches?
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://b...@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
Re: delete dead feature branches?
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
Re: delete dead feature branches?
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
Re: delete dead feature branches?
On Mon, Oct 12, 2009 at 2:15 PM, Jason Merrill ja...@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
Re: delete dead feature branches?
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
Re: delete dead feature branches?
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.
Re: delete dead feature branches?
On Fri, 2009-09-25 at 16:55 +, 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 b...@au.ibm.com Australia Development Lab, IBM
Re: delete dead feature branches?
Jason Merrill ja...@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
Re: delete dead feature branches?
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 jos...@codesourcery.com
Re: delete dead feature branches?
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
Re: delete dead feature branches?
On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill ja...@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.
Re: delete dead feature branches?
On Fri, Sep 25, 2009 at 9:14 PM, Gabriel Dos Reis dosr...@gmail.com wrote: On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill ja...@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.
Re: delete dead feature branches?
On Fri, 25 Sep 2009, Richard Guenther wrote: On Fri, Sep 25, 2009 at 9:14 PM, Gabriel Dos Reis dosr...@gmail.com wrote: On Fri, Sep 25, 2009 at 1:42 PM, Jason Merrill ja...@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 jos...@codesourcery.com
Source control features (Was: Re: delete dead feature branches?)
Quoting Joseph S. Myers jos...@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.
