> From: Nadim Khemir [mailto:nadim.khemir@cpen.com]
> Sent: 17 January 2002 09:17
[...]
> ** 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.
Well, if you don't want to go through the trouble of building
on win32 yourself, why do you complain? Branko provided us with
a working win32 binary (for users to play with and for developers to
bootstrap). So there's your 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.
This is quite normal. You don't have to understand everything, but
if you don't understand what is going on in some section of the project,
patches you send in that apply to one of those sections, are likely
to be useless, only wasting developers time looking at them. Like
any new comer (we've had quite a few and they are still here) read
the docs. Follow the mailing list. Provide comments when they are
appropiate and when you know what you are talking about. Or ask
questions ;)
> 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.
What do you think that barging in the door and yelling:
"Hey I'm new to this project, I need this and that to get
me started. Jump"
will get you? [think about that one before answering]
HACKING is our introduction document for developers, btw.
>> 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.
Err, it certainly felt like flaming. Could you please be
less snide when you simply state something and don't intent to
flame? Thanks in advance.
> 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.
Making the hook too easy to bite isn't good either... ;)
At least now we know that if someone sticks he was serious enough
to at least read all the docs. :)
> ** 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?
Storing stuff _in_ files is badness IMHO. I don't want my version
control system to modify my files (unless it's for EOL conversion/
keyword expansion _and_ I told it to do so).
To move a file we have svn mv <oldfile> <newfile>, btw. The user
needs to tell us about that.
> *** "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".
Ahum: "You think so not us or other think in that way"
> consider it as a requirement entry and think about it as any requirement.
It is not a 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.
There are two(ok, generalizing here) ways to model repositories: centralized
and decentralized. Subversion choose the centralized approach (just like
CVS and many others). Bitkeeper and arch choose the decentralized approach.
If you read the design doc and get to the blue sky items, you will find
something about distributed repositories. It isn't scheduled for 1.0.
> **divers
> thanks for the mail::digest link.
No problem. However, if you want actively want to contribute
it might be a good idea to leave your subscription undigested.
> ** 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.
Finally, something positive ;) :)
> Nadim.
Sander
---------------------------------------------------------------------
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