I hope to start using EBean in my project in the coming month or so.
The current release is 2.7.3 on 23 Mar 2011 with some bugs and
enhancements added to HEAD. I'd like to start with HEAD with the
understanding that some bug fixes may be added to 2.7.3/HEAD but no
significant refactoring or substantial features.
If new development should start up again, I'd like to see a bug fix/
maintenance branch created for 2.7.3 while a new development trunk/
branch moves towards 2.7.4+. Basically if something critical comes up
on 2.7.3 but development is in progress on 2.7.4, I'd like to be able
to get bug fixes on 2.7.3 without upgrading to 2.7.4. Is that
possible? I understand that development is not active at the moment so
I'll likely be able to get bug fixes on 2.7.3/HEAD for some time, but
I'm trying to prepare for the future.
Thanks, looking forward to putting it into real-world use.
The current release is 2.7.4 Oct 12th. Development is on 2.7.5-
SNAPSHOT
Regarding patches to older versions - I'm pretty sure Rob tags all
releases in SVN so we can always reconstruct a version and make any
changes if required.
Be aware that with our limited resources you are more likely to get a
fix to a problem in the current release or even in the dev branch.
If you really want to be on the safe side it is a good idea to
download the source and build Ebean yourself.
Eddie
On Dec 21, 4:26 pm, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> I hope to start using EBean in my project in the coming month or so.
> The current release is 2.7.3 on 23 Mar 2011 with some bugs and
> enhancements added to HEAD. I'd like to start with HEAD with the
> understanding that some bug fixes may be added to 2.7.3/HEAD but no
> significant refactoring or substantial features.
> If new development should start up again, I'd like to see a bug fix/
> maintenance branch created for 2.7.3 while a new development trunk/
> branch moves towards 2.7.4+. Basically if something critical comes up
> on 2.7.3 but development is in progress on 2.7.4, I'd like to be able
> to get bug fixes on 2.7.3 without upgrading to 2.7.4. Is that
> possible? I understand that development is not active at the moment so
> I'll likely be able to get bug fixes on 2.7.3/HEAD for some time, but
> I'm trying to prepare for the future.
> Thanks, looking forward to putting it into real-world use.
On Dec 21, 11:26 am, edge <e.mcgr...@imilia.com> wrote:
> Hi Daryl,
> The current release is 2.7.4 Oct 12th. Development is on 2.7.5-
> SNAPSHOT
Thanks for the clarification.
> Be aware that with our limited resources you are more likely to get a
> fix to a problem in the current release or even in the dev branch.
> If you really want to be on the safe side it is a good idea to
> download the source and build Ebean yourself.
Yes, I'm doing that from HEAD now, I'll spin up a 2.7.4 project and
2.7.5 project. Perhaps I can patch 2.7.4 myself if possible/necessary.
Just a tip that you might find useful:
I also use a local Git repo to keep a track on the ebean code - that
way I can keep old branches locally, see what has changed when I pull
changes from SVN etc.
It is so fast to switch between version and I don't need to mess
around with SVN's branches which suck anyway :(
Maybe I'll convince Rob to move to GitHub at some stage :)
On Dec 21, 5:59 pm, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> On Dec 21, 11:26 am, edge <e.mcgr...@imilia.com> wrote:
> > Hi Daryl,
> > The current release is 2.7.4 Oct 12th. Development is on 2.7.5-
> > SNAPSHOT
> Thanks for the clarification.
> > Be aware that with our limited resources you are more likely to get a
> > fix to a problem in the current release or even in the dev branch.
> > If you really want to be on the safe side it is a good idea to
> > download the source and build Ebean yourself.
> Yes, I'm doing that from HEAD now, I'll spin up a 2.7.4 project and
> 2.7.5 project. Perhaps I can patch 2.7.4 myself if possible/necessary.
On Dec 21, 12:13 pm, edge <e.mcgr...@imilia.com> wrote:
> Just a tip that you might find useful:
> I also use a local Git repo to keep a track on the ebean code - that
> way I can keep old branches locally, see what has changed when I pull
> changes from SVN etc.
Interesting you should bring up Git. I've been the sole developer on
my SVN-based project for years but we're now bringing in another. Been
considering switching, I'm on a pre 1.5 SVN so no merge tracking.
Merges scare me. Anyway, I would appreciate any details on how you do
this. You still use SVN to pull down the latest but then create a
local Git repo from the SVN download?
well I only need to create the Git repo once (it is easy and takes 1
second - git init) and just create a branch for the corresponding SVN
branch. So the procedure is create a new branch in git and pull from
SVN and then commit the changes in Git - so then I have a copy of the
SVN branch and can experiment etc
Git is extremely powerful and can be a bit challenging at the
beginning but no more so than SVN and I've always got it to do what I
wanted.
Branches are cheap on Git and changing from one branch to another is
very fast. There are tools/plugins e.g. egit for Eclipse out there
Anyway, I've used nearly all source control systems down the ages and
Git kicks ass :)
There are tons of examples on the net on setting up Git and getting
started etc
On Dec 21, 6:18 pm, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> On Dec 21, 12:13 pm, edge <e.mcgr...@imilia.com> wrote:
> > Just a tip that you might find useful:
> > I also use a local Git repo to keep a track on the ebean code - that
> > way I can keep old branches locally, see what has changed when I pull
> > changes from SVN etc.
> Interesting you should bring up Git. I've been the sole developer on
> my SVN-based project for years but we're now bringing in another. Been
> considering switching, I'm on a pre 1.5 SVN so no merge tracking.
> Merges scare me. Anyway, I would appreciate any details on how you do
> this. You still use SVN to pull down the latest but then create a
> local Git repo from the SVN download?
On Dec 21, 12:33 pm, edge <e.mcgr...@imilia.com> wrote:
> So the procedure is create a new branch in git and pull from
> SVN and then commit the changes in Git - so then I have a copy of the
> SVN branch and can experiment etc
Great thanks. I'll have the new guy learn Git and teach it to me :-)
Hi github is indeed a very powerful platform. However for java I would
recommend bzr. I used both and must say that it's much easier to learn
bzr than git. This makes contribution easier. The main reason I prefer
bzr is that it tracks moves. So even if you make a refactoring with a
move in it there is no problem to merge it. I created a small example.
SVN/git was a mess after the merge. hg gives you an idea what the
solution could be, but you loose code. bzr makes the job nearly
perfect.
So try it and test it before switch, before switch the VCS. I think
both git/bzr are powerful and fast. Never found a feature on git,
which I missed at bzr.
Niels
On 21 Dez., 18:39, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> On Dec 21, 12:33 pm, edge <e.mcgr...@imilia.com> wrote:
> > So the procedure is create a new branch in git and pull from
> > SVN and then commit the changes in Git - so then I have a copy of the
> > SVN branch and can experiment etc
> Great thanks. I'll have the new guy learn Git and teach it to me :-)
On Dec 27, 11:33 am, PlayDeveloper <opensourc...@googlemail.com>
wrote:
> Hi github is indeed a very powerful platform. However for java I would
> recommend bzr.
Any particular reason it is suited to Java?
> I used both and must say that it's much easier to learn
> bzr than git. This makes contribution easier. The main reason I prefer
> bzr is that it tracks moves.
That's nice.
> So try it and test it before switch, before switch the VCS. I think
> both git/bzr are powerful and fast. Never found a feature on git,
> which I missed at bzr.
I'm seriously considering a hosted service such as GitHub, Fuddle, or
Bitbucket. I see Bazaar has Launchpad but it doesn't look like a
commercial product that can offer us secure access and protection for
a commercial product. Is there some service that supports Bazaar?
On 27 Dez., 19:34, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> On Dec 27, 11:33 am, PlayDeveloper <opensourc...@googlemail.com>
> wrote:
> > Hi github is indeed a very powerful platform. However for java I would
> > recommend bzr.
> Any particular reason it is suited to Java?
Well renaming is in Java a really common operation, because you have a
great refactoring support. In c specially in the kernel, renaming
isn't an important use case. This is the reason why I recommend it for
java. For all other languages it's a nice tool too, but I'm unsure if
it's so much better that I would make a recommendation on a mailing
list.
> > I used both and must say that it's much easier to learn
> > bzr than git. This makes contribution easier. The main reason I prefer
> > bzr is that it tracks moves.
> That's nice.
Yes it's very impressive.
> > So try it and test it before switch, before switch the VCS. I think
> > both git/bzr are powerful and fast. Never found a feature on git,
> > which I missed at bzr.
> I'm seriously considering a hosted service such as GitHub, Fuddle, or
> Bitbucket. I see Bazaar has Launchpad but it doesn't look like a
> commercial product that can offer us secure access and protection for
> a commercial product. Is there some service that supports Bazaar?
On Dec 21, 11:59 am, Daryl Stultz <kungfumachin...@gmail.com> wrote:
> Yes, I'm doing that from HEAD now, I'll spin up a 2.7.4 project and
> 2.7.5 project. Perhaps I can patch 2.7.4 myself if possible/necessary.
I've checked out the 2.7.4 tag from SVN. I'm having trouble building
it. It seems a test is failing:
--------------------------------------------------------------------------- ----
Test set: com.avaje.tests.batchload.TestLoadOnDirty
--------------------------------------------------------------------------- ----
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.041
sec <<< FAILURE!
test(com.avaje.tests.batchload.TestLoadOnDirty) Time elapsed: 0.01
sec <<< FAILURE!
java.lang.AssertionError:
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.assertTrue(Assert.java:37)
at org.junit.Assert.assertNotNull(Assert.java:356)
at org.junit.Assert.assertNotNull(Assert.java:365)
at
com.avaje.tests.batchload.TestLoadOnDirty.test(TestLoadOnDirty.java:
30)
Is this a serious problem? I'm not sure my build environment is set up
right. Some time ago I was building against an earlier version of
maven which doesn't seem to be working anymore. I downloaded Maven 3
which seems to work. What version of Maven should I be using? Here are
some warnings from the build output, not sure if they are significant.
Is there anything helpful in this?
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for org.avaje:ebean:jar:2.7.4
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-source-plugin is missing. @ line 264,
column 21
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-jar-plugin is missing. @ line 251,
column 21
[WARNING] The expression ${pom.version} is deprecated. Please use $
{project.version} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[WARNING]
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building Ebean 2.7.4
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ ebean ---
[INFO] Deleting /Users/daryl/clients/sixdegrees/ebean/target
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 6.034s
[INFO] Finished at: Fri Dec 30 11:52:29 EST 2011
[INFO] Final Memory: 2M/254M
[INFO]
------------------------------------------------------------------------
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for org.avaje:ebean:jar:2.7.4
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-source-plugin is missing. @ line 264,
column 21
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-jar-plugin is missing. @ line 251,
column 21
[WARNING] The expression ${pom.version} is deprecated. Please use $
{project.version} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[WARNING]
[INFO]
> Well renaming is in Java a really common operation, because you have a great refactoring support.
That's not related to version control. Unless you mean tracking code snippets after they got moved to differently-named files - which git can do just fine.
> In c specially in the kernel, renaming isn't an important use case.
The important use case there is code being moved to a different file. A file rename is just a degenerate case where the code snippet is the entire file.
> This is the reason why I recommend it for java. For all other languages it's a nice tool too, but I'm unsure if it's so much better that I would make a recommendation on a mailing list.
The benefits of a new tool are usually dwarved by the cost of moving the entire development history to it.
In this particular case, I do not see what exactly would be easier in bzr, and in what ways.
> However bazaar hosting is so easy, we used at work a simple samba file- server.
A VCS on a Samba server? That's disaster waiting to happen! Samba has a long, long history of corrupting files under concurrent updates if there is any network problem. In other words, it will work "just fine" until network problems strike while two or more updates are in mid-flights. (NFS has the same problem, by the way.)
Regards, Jo
P.S.: A VCS on a Samba server means you haven't even heard about all relevant scenarios, so please don't be annoyed if I'm cautious around your advice.
On 2 Jan., 11:03, "Durchholz, Joachim" <Joachim.Durchh...@hennig-
fahrzeugteile.de> wrote:
> > Well renaming is in Java a really common operation, because you have a great refactoring support.
> That's not related to version control.
> Unless you mean tracking code snippets after they got moved to differently-named files - which git can do just fine.
I think renaming is related to version control specially if you want
to merge easily. My experiences with git in such a situation was
really bad. I thought I made a mistake and ask at github for support.
They was very kindly and tried to help me, but the result was, no it's
impossible. More over the result was that it is impossible by design,
so it would be a great change to make it in git possible.
> > In c specially in the kernel, renaming isn't an important use case.
> The important use case there is code being moved to a different file.
> A file rename is just a degenerate case where the code snippet is the entire file.
Personally I would be really surprised if any VCS can do follow such
changes. Let assume you have a file A with methods foo() and bar(). In
one branch they will be putted into files FOO and BAR. On main foo()
and bar() will be changed. After that the branch will merged back.
Will git this merge without problems? If this something I really want?
> > This is the reason why I recommend it for java. For all other languages it's a nice tool too, but I'm unsure if it's so much better that I would make a recommendation on a mailing list.
> The benefits of a new tool are usually dwarved by the cost of moving the entire development history to it.
> In this particular case, I do not see what exactly would be easier in bzr, and in what ways.
I don't think that this is a good deciding criteria, because all tools
support such a feature. git, hg, bzr can convert one to another and
get the code from SVN or CVS.
> > However bazaar hosting is so easy, we used at work a simple samba file- server.
> A VCS on a Samba server? That's disaster waiting to happen!
> Samba has a long, long history of corrupting files under concurrent updates if there is any network problem. In other words, it will work "just fine" until network problems strike while two or more updates are in mid-flights.
> (NFS has the same problem, by the way.)
OK here you are right it's not optimal, depending on your network. Our
fileserver is reliable enough and we didn't have any problem with it,
with a small team. Concurrency is not a so big issue, because bzr has
a lock-mechanism. How ever for bigger projects you are righter it's
better to setup and special bzr-server, which is far easy too. My
point is that I think it's easier to provide your own infrastructure
than depending on a cloud-service, if we assume that all developer
works in a local network. How ever there exists cloud-solutions for
bzr, hg and git so it's not so important.
> Regards,
> Jo
> P.S.: A VCS on a Samba server means you haven't even heard about all relevant scenarios, so please don't be annoyed if I'm cautious around your advice.
Personally I found it a little bit strange to stress one point of
discussion so much. BTW: I have seen more corrupted files on a SVN-
Server than on a SAMBA-server.
> > > Well renaming is in Java a really common operation, because you have a great refactoring support.
> > That's not related to version control. > > Unless you mean tracking code snippets after they got moved to differently-named files - which git can do just fine.
> I think renaming is related to version control specially if you want to merge easily. My experiences with git in such a situation was really bad. I thought I made a mistake and ask at github for support. > They was very kindly and tried to help me, but the result was, no it's impossible. More over the result was that it is impossible by design, so it would be a great change to make it in git possible.
Without more details, it's really unclear whether that's bad support on the git side or a messed-up local repository on your side (which is easy to do with git, I do agree that git is somewhat hard to learn).
> > > In c specially in the kernel, renaming isn't an important use case.
> > The important use case there is code being moved to a different file. > > A file rename is just a degenerate case where the code snippet is the entire file.
> Personally I would be really surprised if any VCS can do follow such changes.
git can and does. I didn't recognize that Ebean is currently using SVN, I was assuming it's using git already. From that perspective, I do agree that moving from SVN to either bzr or git would probably be a good idea. Not because SVN has problems with renames but because SVN loses the history of all branches but one when merging. And generally because both git and bzr can adapt to a larger set of workflows, so changing the workflow is easier once the need arises. I'm still a bit sceptical about the return on effort though. Moving to a different VCS won't help if you don't use it.
> Let assume you have a file A with methods foo() and bar(). In one branch they will be putted into files FOO and BAR. On main foo() and bar() will be changed. After that the branch will merged back. > Will git this merge without problems? If this something I really want?
git will spot it if the functions were moved without changing their contents. In which case, yes, you usually want the change merged into the moved functions, wouldn't you agree?
(SVN cannot track such moves. If bzr cannot either, I'd chalk that up as a point for git, otherwise as a point for git and bzr.)
> > > This is the reason why I recommend it for java. For all other languages it's a nice tool too, but I'm unsure if it's so much better that I would make a recommendation on a mailing list.
> > The benefits of a new tool are usually dwarved by the cost of moving the entire development history to it. > > In this particular case, I do not see what exactly would be easier in bzr, and in what ways.
> I don't think that this is a good deciding criteria, because all tools support such a feature.
I wasn't talking about a feature-by-feature comparison but about the relative costs of migrating and not having a feature.
> git, hg, bzr can convert one to another and get the code from SVN or CVS.
I have seen that proposed for using git on top of an SVN server. Turns out you lose enough functionality that the advantages become marginal. The server cannot properly handle the semantics of what's happening at the clients, the logs are always less useful (if the semantics are too different, you usually end with less useful information in the logs than if everybody worked with the client that matches the server).
In summary, I'd say that moving to a different VCS is pointless if you stick with the old client and cannot reap the benefits.
> > > However bazaar hosting is so easy, we used at work a simple samba file- server.
> > A VCS on a Samba server? That's disaster waiting to happen! > > Samba has a long, long history of corrupting files under concurrent updates if there is any network problem. In other words, it will work "just fine" until network problems strike while two or more updates are in mid-flights. > > (NFS has the same problem, by the way.) > OK here you are right it's not optimal, depending on your network.
Well, I'm not going to be responsible if that setup flies in your faces :-)
> Our fileserver is reliable enough and we didn't have any problem with it, with a small team. Concurrency is not a so big issue, because bzr has a lock-mechanism.
Last time I looked, it is impossible to do failsafe locking with Samba or NFS in the presence of network problems. I'm not going to test that though :-)
(Network problems could be caused by any networking device on the segment. An IP address collision is enough.)
> BTW: I have seen more corrupted files on a SVN- Server than on a SAMBA-server.
Fair enough, though the cases that I heard about either had people directly accessing the repo without going through the server (a VERY bad idea), or the corruption happened with the old database-based format.
On 4 Jan., 19:42, "Durchholz, Joachim" <Joachim.Durchh...@hennig-
fahrzeugteile.de> wrote:
> > > > Well renaming is in Java a really common operation, because you have a great refactoring support.
> > > That's not related to version control.
> > > Unless you mean tracking code snippets after they got moved to differently-named files - which git can do just fine.
> > I think renaming is related to version control specially if you want to merge easily. My experiences with git in such a situation was really bad. I thought I made a mistake and ask at github for support.
> > They was very kindly and tried to help me, but the result was, no it's impossible. More over the result was that it is impossible by design, so it would be a great change to make it in git possible.
> Without more details, it's really unclear whether that's bad support on the git side or a messed-up local repository on your side (which is easy to do with git, I do agree that git is somewhat hard to learn).
If you interested I can give you the testrep. The comments are
unfortunately in German. My first assumption was that I made a
mistake, how ever the guys from github said, that I have done every
thing right. Would be nice to have a testrep which shows the
possibilities of git.
> > > > In c specially in the kernel, renaming isn't an important use case.
> > > The important use case there is code being moved to a different file.
> > > A file rename is just a degenerate case where the code snippet is the entire file.
> > Personally I would be really surprised if any VCS can do follow such changes.
> git can and does.
> I didn't recognize that Ebean is currently using SVN, I was assuming it's using git already.
> From that perspective, I do agree that moving from SVN to either bzr or git would probably be a good idea. Not because SVN has problems with renames but because SVN loses the history of all branches but one when merging. And generally because both git and bzr can adapt to a larger set of workflows, so changing the workflow is easier once the need arises.
> I'm still a bit sceptical about the return on effort though. Moving to a different VCS won't help if you don't use it.
That's absolutely right and I think it's consensus. How ever the
circumstances of Ebean are pro DVCS, because people haven't so much
time. Then feature-branches is easy. Furthermore it's easier to create
patches, so more people can help. How ever I fear that at the moment
Rob has enough to do, so it's not a topic at the moment. And to make
it clear, I didn't proposed to switch I only say: If Ebean switch I
would recommend bzr.
> > Let assume you have a file A with methods foo() and bar(). In one branch they will be putted into files FOO and BAR. On main foo() and bar() will be changed. After that the branch will merged back.
> > Will git this merge without problems? If this something I really want?
> git will spot it if the functions were moved without changing their contents.
> In which case, yes, you usually want the change merged into the moved functions, wouldn't you agree?
> (SVN cannot track such moves. If bzr cannot either, I'd chalk that up as a point for git, otherwise as a point for git and bzr.)
I tried a short example whit egit and it fail agains. Again I can send
you the repository. I think the sentence (without changing their
contents) it's an important point. Renaming a Class in Java always
change the content :-(
> > > > This is the reason why I recommend it for java. For all other languages it's a nice tool too, but I'm unsure if it's so much better that I would make a recommendation on a mailing list.
> > > The benefits of a new tool are usually dwarved by the cost of moving the entire development history to it.
> > > In this particular case, I do not see what exactly would be easier in bzr, and in what ways.
> > I don't think that this is a good deciding criteria, because all tools support such a feature.
> I wasn't talking about a feature-by-feature comparison but about the relative costs of migrating and not having a feature.
The you are absolutely right, furthermore the cost of learning the new
tool is another think which costs.
> > git, hg, bzr can convert one to another and get the code from SVN or CVS.
> I have seen that proposed for using git on top of an SVN server.
> Turns out you lose enough functionality that the advantages become marginal. The server cannot properly handle the semantics of what's happening at the clients, the logs are always less useful (if the semantics are too different, you usually end with less useful information in the logs than if everybody worked with the client that matches the server).
> In summary, I'd say that moving to a different VCS is pointless if you stick with the old client and cannot reap the benefits.
Totally agree with you git-svn or bzr-svn is not really useful, but
perhaps in some circumstances necessary.
> > > > However bazaar hosting is so easy, we used at work a simple samba file- server.
> > > A VCS on a Samba server? That's disaster waiting to happen!
> > > Samba has a long, long history of corrupting files under concurrent updates if there is any network problem. In other words, it will work "just fine" until network problems strike while two or more updates are in mid-flights.
> > > (NFS has the same problem, by the way.)
> > OK here you are right it's not optimal, depending on your network.
> Well, I'm not going to be responsible if that setup flies in your faces :-)
> > Our fileserver is reliable enough and we didn't have any problem with it, with a small team. Concurrency is not a so big issue, because bzr has a lock-mechanism.
> Last time I looked, it is impossible to do failsafe locking with Samba or NFS in the presence of network problems.
> I'm not going to test that though :-)
> (Network problems could be caused by any networking device on the segment. An IP address collision is enough.)
Yes it can happen, but you always have a clean backup local and it's
should be a really rare that a collision happens.
> > BTW: I have seen more corrupted files on a SVN- Server than on a SAMBA-server.
> Fair enough, though the cases that I heard about either had people directly accessing the repo without going through the server (a VERY bad idea), or the corruption happened with the old database-based format.
In this case it was file based. As far as I remember version 1.5. We
hired some SVN expert. The only advice they give was to upgrade to 1.6
which fixed the problems. Most of the corruptions could be fixed.
> I tried a short example whit egit and it fail agains. Again I can send > you the repository. I think the sentence (without changing their > contents) it's an important point. Renaming a Class in Java always > change the content :-(
> Use the command line client, not Egit ( I assume you're using it through
the eclipse plugin? ) If the file is large enough ( a few lines ), it detects the delete+add without a problem as a move/rename.
As for BZR/GIT/HG etc.
The most active community for creating patches etc. in OSS is in the Git universe... all the big players (apache/eclipse/etc.) are switching over.
Mercurial and BZR may have their advantages, but the communities are quite small compared to git.
On 4 Jan., 21:18, Dominik Dorn <domi...@dominikdorn.com> wrote:
> > I tried a short example whit egit and it fail agains. Again I can send
> > you the repository. I think the sentence (without changing their
> > contents) it's an important point. Renaming a Class in Java always
> > change the content :-(
> Use the command line client, not Egit ( I assume you're using it through
> the eclipse plugin? )
> If the file is large enough ( a few lines ), it detects the delete+add
> without a problem as a move/rename.
If I understand you correct, you say the commandline git can detect it
but the eclipse-integration can't? Then git loose it's good IDE-
Support.
> As for BZR/GIT/HG etc.
> The most active community for creating patches etc. in OSS is in the Git
> universe... all
> the big players (apache/eclipse/etc.) are switching over.
> Mercurial and BZR may have their advantages, but the communities are quite
> small compared to git.
Well and most people use MS-Windows and MS-Office. I don't think that
this is an good argument. As I said above for some projects git is a
good choice, specially the big community, but remember even in the
main reference the kernel, many developer used hg. However if you use
refactoring in java-projects quite often I would recommend bzr. About
the renaming capabilities I only heard from git-fans that it works
fine, but I never saw a running example. I tried together with the
support from github to create such an example and I failed. It would
be great to see that it works, because it's always easier to swim with
the mainstream, but I didn't found any one who shows me.
> If I understand you correct, you say the commandline > git can detect it but the eclipse-integration can't?
He isn't saying that - moves per se are definitely not a problem. I suppose something else is amiss. I wouldn't exclude the possibility of misunderstandings between the github people and you.
> Then git loose it's good IDE- Support.
Egit does not give access to all features that git offers, but those that it offers should work just fine. Disclaimer: Egit uses a Java reimplementation of git. AFAIK the gap in functionality is narrow and ever-closing, but it's not entirely impossible that you got hit by such a difference.
That said, your report is very unusual. As in: I've been scanning git responses for quite a while now, and your experience registered with me as: "Huh? But git doesn't fail in this way!" Doesn't mean your problems weren't real, just so unusual that I'm starting to look for unusual circumstances.
> > The most active community for creating patches etc. in OSS is in the > > Git universe... all the big players (apache/eclipse/etc.) are > > switching over.
> > Mercurial and BZR may have their advantages, but the communities are > > quite small compared to git.
> Well and most people use MS-Windows and MS-Office. > I don't think that this is an good argument.
Dominik's argument can be interpreted in two ways. One is "a million flies can't be wrong". Which is indeed a fallacy. I think he meant "if I hit a problem, I have a better chance to find a solution through my search engine", then the argument stands.
I can take a look at your testrep (German comments are not a problem, I'm a German myself). Be warned that I'm not a git guru - I'd be unable to distinguish a corrupted rep from a merely unusual one, for example. But then my perspective would certainly be different from that of the people at Github, so maybe I can find something.
On 5 Jan., 10:41, "Durchholz, Joachim" <Joachim.Durchh...@hennig-
fahrzeugteile.de> wrote:
> He isn't saying that - moves per se are definitely not a problem. I suppose something else is amiss.
Then I didn't know what he want to say.
> I wouldn't exclude the possibility of misunderstandings between the github people and you.
That's always a possibility, but I send them a detailed description of
the scenario and a test-rep.
> > Then git loose it's good IDE- Support.
> Egit does not give access to all features that git offers, but those that it offers should work just fine.
I know that jgit and therefore egit doesn't support all commands, just
wondering that Dominik recommend to use the commandline.
> That said, your report is very unusual.
> As in: I've been scanning git responses for quite a while now, and your experience registered with me as: "Huh? But git doesn't fail in this way!"
> Doesn't mean your problems weren't real, just so unusual that I'm starting to look for unusual circumstances.
This can be, for me and my collegians it's usual, how ever see my
mail.
> > > The most active community for creating patches etc. in OSS is in the
> > > Git universe... all the big players (apache/eclipse/etc.) are
> > > switching over.
> > > Mercurial and BZR may have their advantages, but the communities are
> > > quite small compared to git.
> > Well and most people use MS-Windows and MS-Office.
> > I don't think that this is an good argument.
> Dominik's argument can be interpreted in two ways.
> One is "a million flies can't be wrong". Which is indeed a fallacy.
> I think he meant "if I hit a problem, I have a better chance to find a solution through my search engine", then the argument stands.
Well I prefer to have a tool where I doesn't need to google. For
hibernate you get thousand results in a google search. However I
prefer Ebean, there I don't need to google so often and have an
excellent google-group. So this is a weak argument. BTW I use both git
and bzr, so I know the difference for searching answers.
> I can take a look at your testrep (German comments are not a problem, I'm a German myself).
> Be warned that I'm not a git guru - I'd be unable to distinguish a corrupted rep from a merely unusual one, for example.
> But then my perspective would certainly be different from that of the people at Github, so maybe I can find something.
I send you the rep via mail. Would be great if you can send me a git
repository which shows the possibilities of git.
> If I understand you correct, you say the commandline git can detect it > but the eclipse-integration can't? Then git loose it's good IDE- > Support.
Yes. The only "good" IDE Support Git ever had is how the IntelliJ IDEA Guys do it.
> > As for BZR/GIT/HG etc.
> > The most active community for creating patches etc. in OSS is in the Git > > universe... all > > the big players (apache/eclipse/etc.) are switching over.
> > Mercurial and BZR may have their advantages, but the communities are > quite > > small compared to git.
Well and most people use MS-Windows and MS-Office. I don't think that
> this is an good argument. As I said above for some projects git is a > good choice, specially the big community, but remember even in the > main reference the kernel, many developer used hg. However if you use > refactoring in java-projects quite often I would recommend bzr. About > the renaming capabilities I only heard from git-fans that it works > fine, but I never saw a running example. I tried together with the > support from github to create such an example and I failed. It would > be great to see that it works, because it's always easier to swim with > the mainstream, but I didn't found any one who shows me.
No, its not about end customers and its definitely not about getting answers to (SCM related) questions.
Its about the size of the developer community & how easy it is to get people to contribute to the project (ebean)... and nothing beats a simple - fork on Github, - do your changes - issue a pull request
Especially as there are already millions of developer accounts on github.
Sure, there are github alternatives for Mercurial, BZR... people could even use SVN/Mercurial on SF.net, but if you want to make it easy for developers to contribute to an OSS project, _right now_ GIT + Github is the way to go.
As for your refactoring example:
create a sample project, add all files to git and commit. refactor some classes to other packages, even rename them. git status shows that some files got removed and others are untracked, add the untracked files and do a git commit -a git see's which files have been moved/renamed and preserves the history accordingly.
As interesting as this thread is I think this is the wrong forum for
discussing Git v Bzr or whatever.
We (Ebean) probably won't change SCS soon but Git would be my choice
as I have experience with it and currently use it locally for Ebean
development in addition to the SF SVN.
> As interesting as this thread is I think this is the wrong forum for
> discussing Git v Bzr or whatever.
> We (Ebean) probably won't change SCS soon but Git would be my choice
> as I have experience with it and currently use it locally for Ebean
> development in addition to the SF SVN.
One last note for people who read this task later. I'm must apologize,
because my statement about git was wrong. There are still small
differences in behavior, but not so fundamental, that git has big
problems with refactorings. My fault was, that I do the whole example
with EGit. After making the merge with git at the command line, the
result was OK. I still prefer bzr and think it worth to have a closer
look on it, but the difference are not so fundamental.
Sorry for that it was not my intention to make git bad and I'm glad to
see that git can handle the situation.
Niels
On 6 Jan., 09:09, PlayDeveloper <opensourc...@googlemail.com> wrote:
> Sorry for entering this thread. I clear the points now directly via
> mail. Would be glad to see that git can handle the renaming.
> Niels
> On 5 Jan., 16:46, edge <e.mcgr...@imilia.com> wrote:
> > Hi Guys,
> > As interesting as this thread is I think this is the wrong forum for
> > discussing Git v Bzr or whatever.
> > We (Ebean) probably won't change SCS soon but Git would be my choice
> > as I have experience with it and currently use it locally for Ebean
> > development in addition to the SF SVN.
