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 source control. And it was already mentioned a full history (.jar’s & all) could be kept somewhere more for archival purposes — which is a good compromise, I think, since “build-ability” of history should be retained (assuming it’s even still possible, given Rob’s comments) but doesn’t have to be convenient (e.g. by it being in a separate repo). +1 to that!
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 trunk, branches, and tags lived. It appears the current repo may have been a blind git import from subversion. And hand-done process that is mindful of these things would result in a nice history. I’ve done this sorta thing once (a project at my last job) and volunteer to do it here if we can get consensus on a move to git. ~ David On Sun, May 31, 2015 at 4:21 PM Dawid Weiss <dawid.we...@cs.put.poznan.pl> wrote: > > 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 and it gets version after version > from CVS or SVN and appends it to git. I admit I didn't care much > about svn merging infos though. Any files can be removed/ pruned by > rewriting git trees before they're published. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
