Le 24/07/2014 12:36, Gilles a écrit :
> On Thu, 24 Jul 2014 11:12:38 +0200, luc wrote:
>> Le 2014-07-23 23:58, Gilles a écrit :
>>> On Wed, 23 Jul 2014 08:36:55 +0200, Luc Maisonobe wrote:
>>>> Le 23/07/2014 00:05, Gilles a écrit :
>>>>> On Tue, 22 Jul 2014 10:01:44 -0700, Phil Steitz wrote:
>>>>>> Looks like other projects are running VOTEs to ensure there is
>>>>>> consensus for this action and including references to VOTE threads
>>>>>> in INFRA JIRAs. Lets do this. The action I am proposing is that we
>>>>>> request a new ASF git repo, make the current svn repo read-only
>>>>>> (adding a README to make it clear) and change github mirroring to
>>>>>> use the git repo. Votes, please. This vote will close in 72
>>>>>> hours. Note that this VOTE applies only to [math], i.e.
>>>>>> http://svn.apache.org/repos/asf/commons/proper/math.
>>>>>> [ ] +1 go for it
>>>>>> [ ] +0 OK, but...
>>>>>> [ ] -0 Not happy about this, because...
>>>>> [X] -1 We should not do this if that means that I have to know how
>>>>> to use "git" within the next 72 hours.
>>>>> Please clarify the migration planning, including the necessary
>>>>> transition
>>>>> for complete newbies (e.g. a summary of how to perform the
>>>>> equivalent of
>>>>> such basic tasks as "svn co", "svn add", svn del", "svn commit",
>>>>> "svn diff").
>>>> There is an extensive tutorial for git as the Git book:
>>>> <http://www.git-scm.com/book>
>>>>
>>>> For a quick reference, here is a cheet sheet for subversion users:
>>>>
>>>>
>>>> <http://www.git-tower.com/blog/git-for-subversion-users-cheat-sheet-detail/>
>>>>
>>>> For an even quicker reference on the most used commands, here is
>>>> a mapping :
>>>> Concerning the other commands, here are some hints:
>>>> svn co ---> git clone
>>>> svn add ---> git add
>>>> svn rm ---> git rm
>>>> svn commit ---> git commit, then git push (rationale explained
>>>> below)
>>>> svn diff ---> git diff
>>>> svn update ---> git pull
>>>> From my own experience, the first thing to understand for the
>>>> difference
>>>> between subversion and git is that in the later there is a separation
>>>> between "committing" a change, and "pushing" it to the reference remote
>>>> repository. The reason this is a two-stage process in git is that there
>>>> are many different repositories and when you "commit" you do it on your
>>>> local repository, which is on your own hard drive. So after this first
>>>> step, the only person who can see the change is the one who can see
>>>> this
>>>> local repository: you. If you want other people to see your change, you
>>>> have to perform the second step and "push" your repository to a
>>>> reference one shared with other developers (i.e. in our case the one on
>>>> Apache infrastructure). This difference seems at first cumbersome for a
>>>> subversion user, and at the beginning we always forget to push and
>>>> don't
>>>> understand why people do not see our commits. After some time, it
>>>> appears really a good thing, as it allows to work locally using full
>>>> source code versioning features without any risk of breaking things on
>>>> the main shared repository.
>>> Thanks, Luc.
>>> If I could just ask:
>>> * What are the actual command(s) to create a Commons Math local
>>> repository?
>>
>> From the command line, using the current read-only version of the
>> repository, this would be :
>>
>>
>> git clone http://git.apache.org/commons-math.git
>>
>> From this, you would be able to do local commits (since you have now
>> a local repository,
>> which is a full-fledge repository, you can commit in it). However,
>> you cannot push to
>> the remote Apache repository afterwards since it is read-only.
>>
>>> * Did I understand correctly that we can already interact with the svn
>>> repository, using a local git repository?
>>
>> Yes. This is what I have done for the last one or two years with
>> Apace Commons Math.
>> There is an extension to git named git-svn that set up a bridge
>> between the two systems:
>> the remote repository is the svn server, and locally you can have a
>> git repository. So
>> from the client side you do your commits using git commands, and when
>> you want to push
>> them the bridge uses svn protocol to communicate with the remote svn
>> server. The server is
>> not aware you are not using svn locally.
>
> Clone created; I modified the "doc/release/release.howto.txt" file and
> tried to commit with the following two commands:
>
> -----
> $ git commit
> On branch trunk
> Your branch is up-to-date with 'origin/trunk'.
>
> Changes not staged for commit:
> modified: doc/release/release.howto.txt
>
> Untracked files:
> doc/release/release.howto.txt~
>
> no changes added to commit
> $ git svn dcommit
> doc/release/release.howto.txt: needs update
> update-index --refresh: command returned error: 1
> -----
>
> What's the problem(s)?
It is the connection with svn that was not done. The command I gave
was probably wrong, the good one is in the link Oliver gave (I was not
able to find it when I wrote my message earlier, sorry for that).
>
> Are there git configurations ready for Commons Math that e.g. will
> ignore backup files (to avoid the above verbose output),
We have not set up one yet, but we could add a .gitignore to the project
itself. Another file we could add it .gitattributes which helps managing
end of line in specific files where we don't want git to translate. Yet
another file could be .mailmap for fixing some author mail, but I doubt
we would really need this one.
Note also that when a workspace is controlled using git, emacs recognizes
it automatically and should not create ~ backup files (I have just
checked again to be sure it also work when we use git-svn). Was this
file created by emacs?
> ignore backup files (to avoid the above verbose output), will set
> the the "keys" ("$Id") and "properties"?
Ah, this is a difference. Git does not have any properties like that
and never changes file content (except for end of line normalization). I
personally find it rather good as properties are often a pain to
maintain correctly.
best regards,
Luc
>
>
> Best,
> Gilles
>
>>
>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
