and then cherry-pick, other people prefer rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against it but Subversion
. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against it but Subversion works well for me today. If
everybody else agrees
personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against it but Subversion works well for me today. If
everybody else agrees on switching
rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against it but Subversion works well for me today
Nice!
On Sun, May 31, 2015 at 1:31 PM Steve Davids sdav...@gmail.com wrote:
bq. Something needs to be done about all those jars in the source
history, I will not let this go.
I went ahead and used the BFG Repo Cleaner
https://rtyley.github.io/bfg-repo-cleaner/ tool to drop all of the old
You guys totally miss the point on clone.
No, I think you miss our point.
The thing is that svn checkout gives you enough, to do what you need
to do.
git clone --depth 1 does as well -- you work on your stuff, then you
diff against the baseline, submit a patch. Like I said -- we differ in
On Sun, May 31, 2015 at 2:32 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Yeah, but it misses the point -- history is history, if there were
jars in it, you shouldn't just strip them, it'd be confusing.
How was it back when Lucene was merging with Solr? Didn't it just
initiate with a
I totally agree Doug. Losing the jars would have a cost: those old
branches wouldn't work out of box if you wanted to run tests on
them.
But I am not sure how bad that cost really is. It might be zero. I
havent tried to run e.g. lucene 2.x tests with a modern java 7 or java
8, but i bet they
I'd like to have full consolidated history, as much as possible,
connect-the-dots across whatever CVS/SVN/etc repos to the extent
maximally permitted by law, as Doug hints at. Just nuke the jars.
I've done this (CVS-SVN-GIT) before. It wasn't that difficult.
Eventually (for git) you script it
There are also some rather large '.dat' files in the history as well, I
found this by running on a job to delete all blobs 5MB from the history
via:
$ java -jar ~/Downloads/bfg-1.12.3.jar --strip-blobs-bigger-than 5M
--protect-blobs-from trunk,branch_5x,branch_4x lucene-solr-mirror
Deleted
You just made my day with that CVS repo! :)
Though I don't really get a vote -- +1 to your plan Robert.
/polishes history degree
-Doug
On Sun, May 31, 2015 at 3:16 PM, Robert Muir rcm...@gmail.com wrote:
I totally agree Doug. Losing the jars would have a cost: those old
branches wouldn't
Losing the jars would have a cost: those old
branches wouldn't work out of box if you wanted to run tests on
Yeah, I'd rather not have them at all than have them filtered and
crippled. It'll be confusing.
There's nothing wrong in preserving the SVN history (or even a full
git import from SVN,
On Sun, May 31, 2015 at 3:53 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Losing the jars would have a cost: those old
branches wouldn't work out of box if you wanted to run tests on
Yeah, I'd rather not have them at all than have them filtered and
crippled. It'll be confusing.
But
bq. Something needs to be done about all those jars in the source history, I
will not let this go.
I went ahead and used the BFG Repo Cleaner
https://rtyley.github.io/bfg-repo-cleaner/ tool to drop all of the old
jars in the git history, here are the findings:
$ git clone --mirror
Yeah, but it misses the point -- history is history, if there were
jars in it, you shouldn't just strip them, it'd be confusing.
How was it back when Lucene was merging with Solr? Didn't it just
initiate with a new clean repo? Maybe not all of the history is really
needed -- if we limited
Subject: Re: Moving to git?
On Sun, May 31, 2015 at 9:31 AM, Ramkumar R. Aiyengar
andyetitmo...@gmail.com wrote:
Personally, clone for me is 'rare', I did it once years back, and have
never done it since. log, diff and others I do on a daily basis.
Yep, I find I need fewer
I like where this is going!
I also think history of source code is very important, but not history of
‘.jar’ files that shouldn’t have been in source control in the first
place. I’m fiercely negative about large binaries or ‘jar’ files that can
be downloaded by the build system (e.g. ivy) in
On Sun, May 31, 2015 at 4:39 PM, david.w.smi...@gmail.com
david.w.smi...@gmail.com wrote:
If we were to come up with a new git repo that doesn’t have the ‘.jar’s,
it’d be good to also streamline the history prior to the big Lucene + Solr
merge due to the paths in source control as to where the
, other people merge into master first
and then cherry-pick, other people prefer rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody
rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against it but Subversion works well for me today
Hmmm. I pulled up this file in IntelliJ in my git checkout and viewed the
history. It went back to March 17th 2010 (earlier than the 2012 you found)
with git hash 3ee0ace1ba6b9bff3ffaa278c0bba07e6064057dwith a commit
message of:
git-svn-id:
I'm all for a small download size in all things, but personally, I download
Git repos for a project about 1/20th as often as I download svn checkouts
(one of the things I prefer about my Git usage) and I have fast internet.
Not a sore spot here.
- Mark
On Sun, May 31, 2015 at 5:38 PM Steve
And here is IndexWriter with initial revision in 2001, but again git
still only stops at Feb 7, 2012.
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java?view=log
Revision 149570 - (view) (download) (annotate) - [select for diffs]
Added Tue
I have no dog in the svn vs git debate honestly.
I want to say how important it is to keep healthy history. I recently went
on a bit of code archeology dig recently to figure out why something in
Lucene was done the way it was. It was handy that the history went as far
back as it did, but I had
+1 for git, great for working on multiple things at once.
Side note: git-svn is also not great btw for the kind of merging we need to
do with every commit, it kind of works but with too many caveats.
On the note that git clone is slow, sure, because it fetches a fair amount
of history which svn
You guys totally miss the point on clone.
The thing is that svn checkout gives you enough, to do what you need
to do. And yes it does network lookup for more rare things like
history, but this works just fine in general.
On the other hand git downloads gigabytes, before you can even get started.
Personally, clone for me is 'rare', I did it once years back, and have
never done it since. log, diff and others I do on a daily basis. Same with
svn as well actually, you checkout just once usually..
I think the previous discussion had the agreement that this issue should
focus on committers
On Sat, May 30, 2015 at 4:20 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
# time git clone --depth 1 https://github.com/apache/lucene-solr.git
This breaks rule #1 of using git, don't pass any options to any of the
commands, or it shits itself.
Git clone is slow, i think the reason is all
Don't assume your workflow is everyone else's workflow. And don't try
to enforce your workflow on me.
I don't use svn OR git in the way you describe.
On Sun, May 31, 2015 at 9:31 AM, Ramkumar R. Aiyengar
andyetitmo...@gmail.com wrote:
Personally, clone for me is 'rare', I did it once years
To: Solr/Lucene Dev
Subject: Re: Moving to git?
On Sun, May 31, 2015 at 9:31 AM, Ramkumar R. Aiyengar
andyetitmo...@gmail.com wrote:
Personally, clone for me is 'rare', I did it once years back, and have
never done it since. log, diff and others I do on a daily basis.
Yep, I find I need
On Sun, May 31, 2015 at 9:31 AM, Ramkumar R. Aiyengar
andyetitmo...@gmail.com wrote:
Personally, clone for me is 'rare', I did it once years back, and have never
done it since. log, diff and others I do on a daily basis.
Yep, I find I need fewer different working directories with git, but
when
+1 to moving to git. I am not going to attempt to convince those stubborn types
that want to stick to SVN. I use git and svn and git simply works better for me.
I just want to explain something, because there seems to be a misunderstanding.
time git clone git://git.apache.org/lucene-solr.git
Did this, out of curiosity (from a server in the U.S.):
# time git clone https://github.com/apache/lucene-solr.git
...
Receiving objects: 100% (563630/563630), 472.01 MiB | 10.46 MiB/s, done.
real1m13.049s
user0m46.000s
sys 0m10.060s
# time git clone --depth 1
...@gmail.com wrote:
+1 to moving to git.
Shai
On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:
* There may be other good reasons for using git, but this is not one.*
I just added one more to the list. I think most other reasons have
already been spoken about in previous
Walter Underwood wun...@wunderwood.org wrote:
I’m not a committer, but I’ve built production code with a lot of source
control
systems and git is by far the the most cumbersome.
I am not a committer and I have build production code with very few source
control systems: CVS, SVN GIT. GIT is
The commit then push workflow *is* what allows you to maintain multiple
local branches without the nightmare of having multiple checkouts, and
managing them.
I don't think that moving to GIT has anything to do with Github. With SVN,
we also don't have any nice user interface and/or pull requests
bq. I don't think that moving to GIT has anything to do with Github.
I think that's a common misconception by people that don't 'get' Git. Most
people could care less about Git as it pertains to GitHub except for one
thing - it provides a nice central master repo that is hosted that you can
push
A git clone is just too slow right now the way its setup. So what will
be done to fix that? Currently, svn is way faster in the worst case.
In the time it takes to git clone, i can do 10 svn checkouts.
I sometimes use git, but usually when working on software, i don't
work on trivial things. I do
and then cherry-pick, other people prefer rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple that everybody agrees on.
-0: I'm not against
: Anshum Gupta [mailto:ans...@anshumgupta.net]
Sent: Friday, May 29, 2015 11:08 PM
To: dev@lucene.apache.org
Subject: Moving to git?
I know this has come up a few times in the past but I wanted to bring this up
again.
The lucene-solr ASF git mirror has been behind by about a day. I
and then to master, other people merge into master first
and then cherry-pick, other people prefer rebasing instead of merging,
etc. I personally don't really care but if we agree on moving to Git,
I hope we can agree on the workflow at the same time. At least today
with svn we have something simple
+1 to move to git!
-Yonik
On Fri, May 29, 2015 at 5:07 PM, Anshum Gupta ans...@anshumgupta.net wrote:
I know this has come up a few times in the past but I wanted to bring this
up again.
The lucene-solr ASF git mirror has been behind by about a day. I was
speaking with the infra people and
On Fri, May 29, 2015 at 9:40 PM, Walter Underwood wun...@wunderwood.org wrote:
“git breaks when it tries to mirror” is not a convincing argument for moving
to git.
I'd be +1 without that annoyance as well. As Anshum mentioned, this
has come up a number of times in the past.
-Yonik
...@wunderwood.org
wrote:
“git breaks when it tries to mirror” is not a convincing argument for moving
to git.
I'd be +1 without that annoyance as well. As Anshum mentioned, this
has come up a number of times in the past.
-Yonik
Life is so much easier on long train/plane journeys with Git. +1.
On Sat, May 30, 2015 at 9:21 AM, Shai Erera ser...@gmail.com wrote:
+1 to moving to git.
Shai
On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:
* There may be other good reasons for using git
with Git. +1.
On Sat, May 30, 2015 at 9:21 AM, Shai Erera ser...@gmail.com wrote:
+1 to moving to git.
Shai
On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:
There may be other good reasons for using git, but this is not one.
I just added one more to the list. I think
...@gmail.com wrote:
On Fri, May 29, 2015 at 9:40 PM, Walter Underwood wun...@wunderwood.org
wrote:
“git breaks when it tries to mirror” is not a convincing argument for
moving
to git.
I'd be +1 without that annoyance as well. As Anshum mentioned, this
has come up a number of times in the past
“git breaks when it tries to mirror” is not a convincing argument for moving to
git. It might be an argument for fixing the mirroring in git.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
On May 29, 2015, at 6:03 PM, Yonik Seeley ysee...@gmail.com
+1 to moving to git.
Shai
On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:
* There may be other good reasons for using git, but this is not one.*
I just added one more to the list. I think most other reasons have already
been spoken about in previous discussions. I'm
to moving to git.
Shai
On May 30, 2015 6:24 AM, Anshum Gupta ans...@anshumgupta.net wrote:
* There may be other good reasons for using git, but this is not one.*
I just added one more to the list. I think most other reasons have
already been spoken about in previous discussions. I'm not trying
I know this has come up a few times in the past but I wanted to bring this
up again.
The lucene-solr ASF git mirror has been behind by about a day. I was
speaking with the infra people and they say that the size of the repo needs
more and more ram. Forcing a sync causes a fork-bomb:
Can't fork:
51 matches
Mail list logo
