I'd like to provide some help improving the documentation

On Wed, Apr 13, 2011 at 2:07 PM, Simon Ochsenreither
wrote:
> Therefore, I'd like to ask if it is possible (and how) to gain the necessary
> rights to fix all these "obvious" little formatting errors, typos, etc. in
> Scala's documentation and ScalaDoc so I can fix and close the "easy" tickets
> myself.

Why not just fork scala on Github and then send extempore (or someone
else) an omnibus documentation fix pull request?

Hi Michael,
> Why not just fork scala on Github and then send extempore (or someone
> else) an omnibus documentation fix pull request?
>

Hi Simon,

We can enable svn commit rights for you; I am writing to you a separate
email with additional details.

Cheers!
Toni

On 13/04/2011 23:07, Simon Ochsenreither wrote:
> Hi everyone,
>
> During the last few weeks I got the feeling that filing bugs for all
> these minor bugs/enhancements regarding the documentation and having
> other people verify, fix and close these tickets (many which I could
> just fix myself within a minute) costs everyone more time than necessary.
>
> Therefore, I'd like to ask if it is possible (and how) to gain the
> necessary rights to fix all these "obvious" little formatting errors,
> typos, etc. in Scala's documentation and ScalaDoc so I can fix and close
> the "easy" tickets myself.
>
> As some people may have already experienced, I can be quite pedantic
> regarding all these details ... I wish to use this character trait to
> improve things and I think it might be a good help in this particular
> job. :-)
>
> Of course, I don't have any plans to mess with the code or
> add/change/remove functionality of the standard library (and afaik every
> commit has to be reviewed).
>
> Thanks!
>
> Bye,
>
> Simon
>
>

Hi Cunei,

> We can enable svn commit rights for you; I am writing to you a separate
> email with additional details.

Thanks very much!

I have some (mostly stupid I guess) questions ...

- Is there some description of the recommended workflow somewhere?

- Are there additional tools recommended for working with SVN/Git?

- I just wonder what's the workflow of people which have SVN commit
access and work on Git/Github. Do they have a Git locally, with some
"svn export" tool and various remote Git repos? Or is just committing
to Github's scala/scala enough and SVN syncs from there automatically?

- How can I let others review my changes? Is it an automatic step,
before things get committed? Or is there manual work required? Are
there rules when review is mandatory and when I can write "no review"?

- What about creating a branch? Are there special requirements for
it? (Afaik branching/merging is cheap in Git but expensive in SVN) As
an example: #4276.
Would it make sense to throw the various proposals about additional
methods into a branch, so that work isn't duplicated and deciding if
inclusion is warranted gets easier?

- I heard that there were plans to transition from trac to JIRA for
bug tracking. Are there any steps/changes necessary now? I have seen
that most people have stopped filling in the field "fixed in version"
in Trac ... is that related to that?

I hope I can adapt my workflow to that so that in the near future (I
guess I still have to grok Git :-D).

Thanks, again and bye!

Simon

I have some (mostly stupid I guess) questions ...

Well, they're not stupid as far as I'm concerned--I'm really interested in the answers, particularly about how to work with both git and SVN. 

  - What about creating a branch? Are there special requirements for  

it? (Afaik branching/merging is cheap in Git but expensive in SVN) 

I believe that in SVN, branching is expensive if you are working with a _copy_ of the repository (that is, if you do a co and then branch off of that), but cheap if you branch the main repo directly. Of course, you'd be working with the copy, so branching would be expensive, so it's not like I'm saying anything useful :-), but I just wanted to demonstrate one of the very small number of things I (think I) know about SVN.
Cheers,Ken

On 4/16/11 12:10 PM, Ken McDonald wrote:
> I have some (mostly stupid I guess) questions ...
>
> Well, they're not stupid as far as I'm concerned--I'm really interested in the
> answers, particularly about how to work with both git and SVN.
>
> - What about creating a branch? Are there special requirements for
>
> it? (Afaik branching/merging is cheap in Git but expensive in SVN)

Tagging and branching is a O(1) operating in svn if you do it server side (if
you use svn cp URL URL), which is the recommended method and the way people tag
and branch 99.99% of the time. When people talk about mergeing with svn, the
are referring to it being a harder process than what git and hg provides.

> I believe that in SVN, branching is expensive if you are working with a _copy_
> of the repository (that is, if you do a co and then branch off of that), but
> cheap if you branch the main repo directly. Of course, you'd be working with the
> copy, so branching would be expensive, so it's not like I'm saying anything
> useful :-), but I just wanted to demonstrate one of the very small number of
> things I (think I) know about SVN.

One normally doesn't and shouldn't branch from a working copy, as most likely
one would create a branch off of mixed revision numbers, and people looking at
the branch couldn't say, this came from revision N from the trunk. Mixed
revision working copies are a natural occurrance after once commits.

The recommended way with working with a new branch, assuming you have a trunk
checked out that you want to use for the branch, is

svn cp http://url/to/project/trunk http://url/to/project/branches/new_tag_name
cd /path/to/my/trunk
svn switch http://url/to/project/branches/new_tag_name

The "svn switch" is similar to "git checkout".

Blair