Closed GoogleCodeExporter closed 8 years ago
> 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
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
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
"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
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
Closing. Moved to git.
Original comment by glenn.re...@gmail.com
on 14 Aug 2008 at 7:53
Original issue reported on code.google.com by
glenn.re...@gmail.com
on 16 Feb 2008 at 6:27