delete dead feature branches?

delete dead feature branches?

[Jason Merrill]

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

Re: delete dead feature branches?

[Ian Lance Taylor]

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

Re: delete dead feature branches?

[Joseph S. Myers]

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

Re: delete dead feature branches?

[Jason Merrill]

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?

[Gabriel Dos Reis]

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.

Re: delete dead feature branches?

[Richard Guenther]

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.

Re: delete dead feature branches?

[Joseph S. Myers]

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

Source control features (Was: Re: delete dead feature branches?)

[Joern Rennecke]

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.

Re: delete dead feature branches?

[Ben Elliston]

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

Re: delete dead feature branches?

[Paolo Bonzini]

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?

[Jason Merrill]

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?

[Andrew Pinski]

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

Re: delete dead feature branches?

[Jason Merrill]

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?

[Michael Matz]

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?

[Jason Merrill]

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?

[Ben Elliston]

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

Re: delete dead feature branches?

[Daniel Berlin]

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
>

Re: delete dead feature branches?

[Joern Rennecke]

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.

Re: delete dead feature branches?

[Jason Merrill]

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

Re: delete dead feature branches?

[Alexandre Oliva]

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

Re: delete dead feature branches?

[Michael Matz]

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?

[Ben Elliston]

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?

[Gerald Pfeifer]

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