[webkit-dev] [webkit-changes] [52439] trunk/WebCore

[Eric Seidel]

Sorry, I meant to say "instead of Git". :)

bugzilla-tool (or really scm.py) is completely agnostic wrt SCM
system, so I just relaunched the commit-queue from an SVN checkout
instead of a Git checkout.  I expect it will continue to work just
fine, if slightly slower.

-eric

On Tue, Dec 22, 2009 at 10:47 PM, David Kilzer <ddkilzer at webkit.org> wrote:
> You mean it's using git-svn instead of just git now?
>
> In my original message, I meant that it should be using a local svn working directory (no git at all) to fix the file history issue.  I'm sure that would present a number of issues, though, not the least of which would be much slower operation.
>
> Dave
>
>
>
> On Tue, December 22, 2009 8:29:09 PM, Eric Seidel wrote:
>
>> Done.  The commit-queue is now using an SVN checkout of Git.
>>
>> -eric
>>
>> On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak wrote:
>> >
>> > On Dec 21, 2009, at 12:22 PM, Eric Seidel wrote:
>> >
>> >> I'm happy to move the commit-queue to use an SVN checkout instead if
>> >> that would be a desired change. :)
>> >
>> > Yes please.
>> >
>> >  - Maciej
>> >
>> >>
>> >> -eric
>> >>
>> >> On Mon, Dec 21, 2009 at 2:20 PM, David Kilzer wrote:
>> >>>
>> >>> If you want to make sure you're not going to lose history, you should use
>> >>> svn directly.  The svn-apply script already knows all the magic to do the
>> >>> right thing...if you used svn-create-patch to create the patch *and* if
>> >>> you're committing to an svn repository.
>> >>>
>> >>> The "git svn dcommit" command (especially in newer versions of git) will
>> >>> try to relate source files that are moved or copied, but it only uses a
>> >>> heuristic when committing.  Using the "--dry-run" switch may provide some
>> >>> insight into whether git will show copied/moved files or not, but I've never
>> >>> tested it to make sure how accurate it is compared to the actual commit.
>> >>>
>> >>> If the commit-queue is using a git repository, it will only work as well
>> >>> as git's heuristic does.
>> >>>
>> >>> Setting "[diff] renames = copies" in ~/.gitconfig or in your .git/config
>> >>> file for each project will make git diff try to do rename detection when
>> >>> creating a patch.  (You may also use "--find-copies-harder" or
>> >>> "--find-copies-harder -C" switches on the command line.)  This will provide
>> >>> hints in the git diff about file renames, but it still only uses a
>> >>> heuristic, and svn-apply currently doesn't know about these hints:
>> >>>
>> >>> Bug 32834: svn-apply should handle git patches with similarity index,
>> >>> rename and copy directives
>> >>> https://bugs.webkit.org/show_bug.cgi?id=32834
>> >>>
>> >>> Also note that --find-copies-harder doesn't work on small files (files
>> >>> under a certain number of lines), although I don't know what that threshold
>> >>> is off the top of my head.
>> >>>
>> >>> I've also seen git think that a new header file (whose license text is
>> >>> larger than the header code itself) is actually a copy of another similarly
>> >>> short header file when doing large merges.
>> >>>
>> >>> Again, you should use svn if you want to ensure file history.
>> >>>
>> >>> Dave
>> >>>
>> >>>
>> >>> On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote:
>> >>>
>> >>>> If such git magic exists, it would be possible to teach svn-apply to use
>> >>>> it.
>> >>>>
>> >>>> -eric
>> >>>>
>> >>>> On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler wrote:
>> >>>>>
>> >>>>> On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote:
>> >>>>>
>> >>>>>> Sorry about that - it was git's decision.
>> >>>>>
>> >>>>> It that’s the case, then please consider not using git for this type of
>> >>>>> change
>> >>>>
>> >>>> in the future. We don’t want to unnecessarily lose repository history
>> >>>> when such
>> >>>> changes occur.
>> >>>>>
>> >>>>> If a git expert can show you how to do such changes with git while
>> >>>>> preserving
>> >>>>
>> >>>> the Subversion history, then that gives you another option.
>> >>>>>
>> >>>>>   -- Darin
>> >>>>
>> >>>
>> >> _______________________________________________
>> >> webkit-dev mailing list
>> >> webkit-dev at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>
>