"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| You can always see them with the [EMAIL PROTECTED] syntax
|
| ie
| svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
| >>>
| >>> Which requires remembering an arbitrary revision nu
On Mon, 2005-10-31 at 03:08 +0100, Gabriel Dos Reis wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
>
> | Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> |
> | >> You can always see them with the [EMAIL PROTECTED] syntax
> | >>
> | >> ie
> | >> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
You can always see them with the [EMAIL PROTECTED] syntax
ie
svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
>>>
>>> Which requires remembering an arbitrary revision number (i.e.,
>>> making life *harder* not *easier* for people
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Joseph S. Myers <[EMAIL PROTECTED]> wrote:
|
| >> You can always see them with the [EMAIL PROTECTED] syntax
| >>
| >> ie
| >> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
| >
| > Which requires remembering an arbitrary revision number (i.e., mak
Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>> You can always see them with the [EMAIL PROTECTED] syntax
>>
>> ie
>> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
>
> Which requires remembering an arbitrary revision number (i.e., making
> life *harder* not *easier* for people looking for that
On Sun, 30 Oct 2005, Daniel Berlin wrote:
> > I fail to see any reason for this. When you don't need a file anymore, you
> > delete it. When you don't need a directory anymore, you delete it. I can't
> > see
> > why it should be any different for branches. Deleting a branch makes life
> > easier
On Mon, 2005-10-31 at 01:18 +0100, Giovanni Bajo wrote:
> Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>
> >> For old branches that are dead and of no use (because they are
> >> merged into newer branches), I'm include to rm them, and for old
> >> branches that have ideas, but, may never see the lig
Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>> For old branches that are dead and of no use (because they are
>> merged into newer branches), I'm include to rm them, and for old
>> branches that have ideas, but, may never see the light of day, be
>> conservative and leave them alone.
>
> I'd rather
On Sun, 30 Oct 2005, Mike Stump wrote:
> For old branches that are dead and of no use (because they are merged into
> newer branches), I'm include to rm them, and for old branches that have ideas,
> but, may never see the light of day, be conservative and leave them alone.
I'd rather put dead bra
Mike Stump wrote:
> On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote:
>
>> I'm not quite sure who can approve this, but I think probably I can.
>> So, I'll approve it, conditional on no objections for 72 hours.
>
>
> Would be nice to have a general well established policy that everyone
> can f
On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote:
I'm not quite sure who can approve this, but I think probably I can.
So, I'll approve it, conditional on no objections for 72 hours.
Would be nice to have a general well established policy that everyone
can follow, baring other reasons for no
Daniel Berlin wrote:
> Diego already said it was okay, and since they were his tags, i did
> it :)
Well, then. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Sun, 2005-10-30 at 10:23 -0800, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> > Okay, well, consider this an official proposal to remove:
> >
> > 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> > into tree-ssa, *not* the other way around
> > 2. the ast-optimizer-branch
On Oct 29, 2005, at 7:54 PM, Daniel Berlin wrote:
1. Apple tags should go in a subdirectory named "apple".
Hey, I already had that thought, I don't want to see all your tags in
my tags directory! :-)
Done.
2. All the old old-gcc tags should go in a subdirectory named "old-
gcc".
I'm no
Daniel Berlin wrote:
> Okay, well, consider this an official proposal to remove:
>
> 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> into tree-ssa, *not* the other way around
> 2. the ast-optimizer-branch merge tags
> 3. structure-aliasing-branch merge tags.
> 4. tree-clean
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> The libc, make, gnumach and hurd tags are presumably mistakes - tags from
> other projects having been in the same repository
Some files (like config.{guess,gcc} and alloca.c) were once shared (via
symlinks) with various other repositories.
Andrea
On Sunday 30 October 2005 10:02, Daniel Berlin wrote:
> 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> into tree-ssa, *not* the other way around
> 2. the ast-optimizer-branch merge tags
> 4. tree-cleanup-branch merge tags
>
OK.
> along with any other mistaken tags (and branches).
>
> I think merge tags for active branches should be the responsibility of the
> branch maintainers to do as they wish with. Merge tags and branchpoint
> tags from branches that have been completely merged into mainline can
> probably go, su
On Sun, 29 Oct 2005, Ian Lance Taylor wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > 1. Apple tags should go in a subdirectory named "apple".
> >
> > (Whether you guys want to further subdivide your taggings, is your
> > business)
> >
> > Not to single apple out, i imagine anyone who
Daniel Berlin <[EMAIL PROTECTED]> writes:
> 1. Apple tags should go in a subdirectory named "apple".
>
> (Whether you guys want to further subdivide your taggings, is your
> business)
>
> Not to single apple out, i imagine anyone who wants to do daily or
> significant amounts of tagging should h
20 matches
Mail list logo
