> Haha...if you want, a friend of mine just wrote a Subversion book.  We
> can consult him for advice.  :-)

+1!  hehe

I guess I wasn't thinking of:

> /tags
> ./project_milestones
> ../some_big_event_we_are_proud_of

I definitely agree that wouldn't be handled well with trunks everywhere.
...hmmm...With that in mind, all I can say is "I'm flexible!"  :-)

I liked the following line so much, I'm also going to end my email with it! 

> We're one project.  We should have one trunk.

Roberto


> -----Original Message-----
> From: Clinton Begin [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 16, 2005 1:11 AM
> To: roberto
> Cc: [email protected]
> Subject: Re: ASF TODO [short] (was ASF TODO [long])
> 
> Haha...if you want, a friend of mine just wrote a Subversion book.  We
> can consult him for advice.  :-)
> 
> But for now, here's mine:
> 
> First, what is trunk, tags and branches?  In Subversion, they're just
> copies. Nothing more.  None of them actually has any meaning.  For the
> most part, they're just recommended naming conventions for the *root*
> directory structure of a repository.
> 
> >> distributions with their own releases, then I think
> >> it'll be easier to work with releases (and their matching
> >> tags) that way...
> 
> It won't make a bit of difference.  It's just an extra directory level.
> 
> > Then a tag like mapper_1_5_0 would be created from /trunk/cs/mapper in
> this
> 
> Given the global nature of revision numbers, we should always tag the
> entire repository anyway.  I guess the question is:  do we have one
> repository, or many?  If we have one, we should tag the whole thing
> (Java/.NET whatever).  Tags are practically free, and they won't
> conflict.  So there's no need to worry about the redundancy.  Tags are
> also less important in SVN, and they're really just copies (as is a
> branch --no difference).
> 
> > looking through a list of combined Java
> > and .NET tags.
> > + How would you like to have your tags created/named/organized in the
> tags
> > folder?
> > + What should each tag contain (in terms of files)?
> > + From what top-level folder should the files for the tag come from or
> be
> > copied from?
> 
> There's no reason why you couldn't organize your tags regardless of
> your project directory structure.  In fact, it's even better this way.
> Because no assumptions have been made about your project structure,
> your tags are free to be organized indepenedntly of it. Of course, you
> could _only_copy the .NET resources if you really want.  You could
> easily have:
> 
> /tags
> ./java_releases
> ../2.0.9
> .../java
> ../2.1.0
> .../java
> ./net_releases
> ../1.0.1
> .../cs
> ../1.4.8
> .../cs
> 
> **IMPORTANT**
> 
> I will ask the opposite question of you.
> 
> If you have this structure (multiple trunks):
> 
> /cs
> ./trunk
> /java
> ./trunk
> /site
> ./trunk
> 
> **THEN** How do you create a project-wide tag of the entire repository?
> 
> You can't.  Not without a completely ridiculous end result of this:
> 
> /tags
> ./project_milestones
> ../some_big_event_we_are_proud_of
> .../cs
> ..../trunk
> .../java
> ..../trunk
> .../site
> ..../trunk
> 
> That's nasty --trunk directories in a project wide tag.
> 
> We're one project.  We should have one trunk.
> 
> Best regards,
> 
> Clinton
> 


Reply via email to