[omniORB] omniORB development moved to Subversion

[Duncan Grisby]

Hi Everyone,

I have (at long last) moved omniORB to a Subversion repository. The CVS
tree is now dead and will no longer be updated. All the history has
migrated into Subversion, so code historians can still access things of
interest.

The repository is still hosted by SourceForge. This page has generic
instructions:

http://sourceforge.net/projects/omniorb/develop

As part of the move, the repository has been somewhat reorganised. It
can be useful to explore it through the web access:

http://omniorb.svn.sourceforge.net/viewvc/omniorb/

This page explains the repository organisation:

http://omniorb.sourceforge.net/development.html

The most significant change is that omniORBpy is now linked into the
omniORB branching structure, rather than having its own version numbers
and branches. Once upon a time, the release schedules of omniORB and
omniORBpy were separate, but they have been linked together for a long
time now. With the future omniORB 4.2.0 release, omniORBpy will get the
same version number, rather than having a separate version.

Hopefully that all makes sense. Let me know if you have any questions or
comments...

Cheers,

Duncan.

[Stefan Naewe]

Post by Duncan Grisby
Hi Everyone,
I have (at long last) moved omniORB to a Subversion repository. The CVS
tree is now dead and will no longer be updated. All the history has
migrated into Subversion, so code historians can still access things of
interest.
The repository is still hosted by SourceForge. This page has generic
http://sourceforge.net/projects/omniorb/develop
As part of the move, the repository has been somewhat reorganised. It
http://omniorb.svn.sourceforge.net/viewvc/omniorb/
http://omniorb.sourceforge.net/development.html
The most significant change is that omniORBpy is now linked into the
omniORB branching structure, rather than having its own version numbers
and branches. Once upon a time, the release schedules of omniORB and
omniORBpy were separate, but they have been linked together for a long
time now. With the future omniORB 4.2.0 release, omniORBpy will get the
same version number, rather than having a separate version.
Hopefully that all makes sense. Let me know if you have any questions or
comments...

Yes. One.

Why subversion and not git ?


Regards,
Stefan

[Felix Nawothnig]

Post by Duncan Grisby
I have (at long last) moved omniORB to a Subversion repository.

This is great - and the timing is perfect, I just got back to the project
I need the event-loop integration for.

And about that - a question: Would implementing another interceptor, (any
naming suggestions? I'd call it signalledMainThread) be okay?

Doing something along the lines of omniORB::setLogFunction() would be
easier, but an interceptor just seems to be the right thing to do here, as
the thing I want to hook really is just another part in the "call chain".

Cheers,

Felix

[Floris Bruynooghe]

Post by Duncan Grisby
Hi Everyone,
I have (at long last) moved omniORB to a Subversion repository. The CVS

Thanks for the work!

Regards
Floris

[Duncan Grisby]

Post by Stefan Naewe
Why subversion and not git ?

Because I use Subversion in other things, so I understand it well. I've
never used git. What am I missing?

Duncan.

[Michael]

Actually you're missing a lot, git is a lot better for many reasons:
- working offline
- doing a lot of commits to a local repository without polluting the
"master" (if you decide to have one)
- Easy lightweight branching
- Merging works really really well (especially compared to SVN where is
this a total pain)
- Has an object database, so it can easily track files by identity (so
moving files within a repository will be tracked).
- Many more :) (there's so much material online, google for yourself)

It might be worthwhile to watch Linus Torvalds' presentation of git on
youtube (even so he of course is totally biased and has "strong opinions").

On the negative side, organizing your repository structures needs more
thinking upfront and you need external tools to emulate a more SVN like
behaviour (e.g. gitosis which works really great). On the bright side
correcting mistakes is really easy cause branching merging etc. are so
cheap (I assume this is the same for other systems like Hg or bitkeeper
which follow the same basic conecpts, but git seems to be the way to go
right now).

To me it always felt like svn is basically about perfectioning cvs's
misconceptions, so for some of my own prjects I actually moved back from
svn to cvs, for the rest I moved forward to git.

Then again, for ominORB's development model I don't think the versioning
system used really matters (how many people are actively committing or
using unstable branches?!??). And of course, almost everybody knows how
to use sv nowadays.

But in general I would suggest you to get used to rcs systems like git,
because they seem to be they way to go in the future (and if you look
how many oss projects moved to git or mercurial there are definitely
benefits of doing so)

cheers
Michael

Post by Duncan Grisby

Post by Stefan Naewe
Why subversion and not git ?

Because I use Subversion in other things, so I understand it well. I've
never used git. What am I missing?
Duncan.

[Allan Wind]

Post by Duncan Grisby
Because I use Subversion in other things, so I understand it well. I've
never used git. What am I missing?

Michael covered a lot of ground already.

I use `git grep` frequently as it so fast on a hot cache, and
`git bisect` is an interesting way to go about fixing defects.
Working offline with support for cheap branching is really
addictive. git log is much faster than svn on our repository.

Each repository is a backup and I like how you can interface with
git passively over ssh for my own projects (no networked servers
other than ssh). You can run a git server like what you are used
to with svn, or outsource that to the github or gitorious of the
world.

git works nicely as a client of an upstream svn repository. This
allows you to use git on the client side to get your feet wet,
and then you switch the server later if you so desire. It has
been a while since I used anything else to interface with svn
upstream.

The python guys went with mercurial over git, and I am sure that
is a good choice too. Even if you keep omniorb on svn I
encourage you to give git and/or mercurial a whirl.


/Allan

[Stefan Naewe]

Post by Duncan Grisby

Post by Stefan Naewe
Why subversion and not git ?

Because I use Subversion in other things, so I understand it well. I've
never used git. What am I missing?

For example: http://github.com/snaewe/omniorb


Regards,
Stefan