RE: New comer

Answer to
> From: Branko Cibej [mailto:brane@xbc.nu]
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> From: Greg Stein [mailto:gstein@lyra.org]

** answer to "getting started"
 
> Granted that the Win32 build instructions could be better,
> more verbose, with nice pictures and luser friendly examples, even in this
> pre-alpha stage we happen to be in. However, quite a few people who've actually
> _read_ that part of the HACKING file and _followed_the_instructions_
> have managed quite nicely.

That was not the point. I do not mean a flashy documentation, just a "GET THE THING RUNNING ON WIN32 NOW!" document

> Let's make a deal: Read and follow the building instructions
> until you get a working Win32 svn binary, and take notes along the way.
What's the use if I can download a binary YOU made ;-) I understand this is the dev mailling list, but even devloppers can get an easy start.

> Then use those notes to update the Win32 build instructions in
> HACKING, and post the patch to the list. In return, I promise to review and, if
> acceptable, commit the change.

I have the feelling this is a bad deal for me. It's exactly what makes new comer quit. Read and understand the whole thing and then provide a patch. Not a smooth start for a new comer. If no one else, that has already some knowledge, want to do that, I will jump in and do as you propose.I'll start by reading the HACKING file.

PS. note that all this is exactly the oposite of what I asked for. A simple intro document that get's me running. Now I am going to look into HACKING, great! I also have a linux box in a corner that might be the shortest path.

> trying to make the Win32 port work, keeping the docs up to date and maintaining the
> necessary binary distros of neon and Berkeley DB to just sit
> quietly and be flamed
That was not flamming, and I don't feel flamed by your mail either.

> Think "in development". Think "can I help?"
Think "new comer, think "one more brain", "10 more fingers" ,and "some sleepless nights", in the project if he bites the hook. Make the hook easy to bite.

** functionality

*** tag
> > - In arch, there is a way to tag a file so arch can see if
> > it has been moved or renamed. that's a great idea. Is it planned in SVN?
>
> Haven't had a chance to study arch yet. So I'm not sure what you mean
> by "tag a file" to detect renames. Subversion supports renames, and
> doesn't lose track of the history.

I do not use arch either but I read their design document. If you add a line in your source file that looks (for example) like:

"THIS_IS_AN_ARCH_TAG: this_is_a unique_id_for_this_very_file"

within the begining of the file.When arch stores the file it also stores the unique id. if one move the file (but does not let arch know about it), arch will automatically detect that the file was moved. I think it's practical to let the tool do the work. Does SVN support anything ressemlant to this?

*** "local" repository
> Unlike Bitkeeper and Arch, Subversion wasn't designed to have a big
> hierarchy of decentralized repositories. It was designed to be
> similar to (but better than) CVS, and for that reason it still uses
> the "one repository" model. However, after we reach 1.0, we're still
> in a far-better position to add inter-repository communication than
> CVS is. And we hope to do that someday.

> That *does* mean that you can't do multiple commits to a
> local repository, and then sync those up to a master repository.

Again, I think this is the most important feture in a version control system. please do not answer with "You think so not us or other think in that way". consider it as a requirement entry and think about it as any requirement. Now if someone thinks it NOT a very good idea and can explain why, I am all ears and would gladely learn something from that person. I feel positive that it is possible to have it in a future version and hope it will soon be here.

**divers
thanks for the mail::digest link.

** positive thoughs
-nice to get answers this fast
-nice to see how active devloppement is.
-using apache as a network layer is one very good idea. I never thought about it that way.

Nadim.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:56 2006