SVN dir layout is non-standard. No code should live outside of trunk/ dir

[GoogleCodeExporter]

In the latest file re-org (wow, lots of file/dir re-orgs.  unstable across 
every release) the plugins 
dir is outside of the trunk (as well as inside the trunk).  To work properly 
with branches and tags 
no code should live outside of the trunk.  The entire project source should be 
self-contained 
under trunk.

The branches dir has been removed. There should be a branches dir that is a 
sibling of tags and 
trunk.  This is standard SVN convention and even if you don't plan to use it 
others might who 
access your code.

So the dirs should look like:

blueprintcss
  wiki
  blueprint
    branches
    tags
    trunk
      CODE

Cheers,

Glenn

Original issue reported on code.google.com by glenn.re...@gmail.com on 16 Feb 2008 at 6:27

[GoogleCodeExporter]

> In the latest file re-org (wow, lots of file/dir re-orgs.  unstable across 
every release) the plugins 

As we're not 1.0 yet, I don't think we should be to afraid of reorganizing, as 
long as the result is a big 
improvement, which in this case, it is.

As far as I can see, the branches dir is still present.

The plugins dir outside trunk is for plugins not bundled with the main 
releases. I don't think these are big enough 
to have their own branches/tags/trunk structure, although I might be wrong. It 
might be a better idea to have just 
one plugin directory, and to oick and chose when we're packing up a new release.

Original comment by ola...@gmail.com on 17 Feb 2008 at 10:00

[GoogleCodeExporter]

Hi,

Yes your branches dir probably is there.  I view the SVN repos through Git and 
Git does not track empty dirs.  
So if it is empty that would explain that.

The main reason I filed the 'bug' though is that there is code living outside 
of the trunk dir.  SVN wants all 
code inside trunk, otherwise it is not possible to take a snapshot of the trunk 
and tag or branch it (while 
including ALL code for the project in that TAG or BRANCH).

So plugins should move inside trunk, and if not all will be used they should in 
general either be removed 
(although they still live in svn history) or a config mechanism setup so you 
can include in the build only those 
that you want.

Original comment by glenn.re...@gmail.com on 17 Feb 2008 at 11:25

[GoogleCodeExporter]

The plugins are now moved to their own downloads, as there wasn't any 
development on them anyway. Our SVN 
directory structure should now be pretty standard.

Should we be using the branches dir for anything? 

Thanks Glenn. :)

Original comment by ola...@gmail.com on 18 Feb 2008 at 5:42

[GoogleCodeExporter]

"Should we be using the branches dir for anything? "

Well, here is where I make my pitch for Git.  :-)

Most SVN developers don't use the branching functionality of SVN because 
although it is very easy to create a 
branch (works the same as making a tag, its a so called cheap copy of the trunk 
at a moment in time) it is 
hard in SVN to merge the code back to the trunk reliably.

With Git they make branching, and more importantly merging, a trivial and even 
fun exercise. A really good 
practice which I find myself doing often now that I have switched to Git, is to 
create so called 'topic' branches, 
which simply means that every time you want to add a feature, or fix a bug, you 
make a simple branch of the 
full project code, fix your bug or feature there on that branch (and test it 
there) and then only when it is fully 
working and tested do you merge it back to the trunk.  This keeps the trunk 
clean and should always be in a 
working state for anyone who downloads at that moment (no work in progress 
allowed on the trunk).

This gives you a feel for it it you want to experiment.

http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

You can actually use Git with SVN repo's in the back as well using the git-svn 
command.  So I pull from your 
SVN repo now with Git, but still have the ability to push my Git commits back 
to the trunk as if they were SVN 
commits.  For my own projects I am converting over to Git exclusively since its 
so much better.

Here's one of my public projects as an example:

http://github.com/grempe/amazon-ec2/tree/master

Cheers.  G

Original comment by glenn.re...@gmail.com on 18 Feb 2008 at 6:06

• Changed state: Verified

[GoogleCodeExporter]

Sounds good. Git is very exciting, I'll read up on it. :)

Original comment by ola...@gmail.com on 18 Feb 2008 at 6:29

[GoogleCodeExporter]

Closing.  Moved to git.

Original comment by glenn.re...@gmail.com on 14 Aug 2008 at 7:53

• Changed state: Fixed