On Thu, Jan 17, 2002 at 09:17:09AM +0100, Nadim Khemir wrote:
> > 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
If we had the document, then we'd point you to it. But really... take a look
at the HACKING document. It is reasonbly well organized. You don't need to
read the whole thing.
> > 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.
Branko was talking about building your own binary. Yes, you could just
download a binary. "Read and follow the building instructions"
The HACKING document is our "easy start" document.
> > 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.
Have you read HACKING yet? Until you do, then you can't know whether it will
be easy or hard...
> It's exactly what makes new
> comer quit. Read and understand the whole thing and then provide a patch.
It is an introduction. You don't have to understand everything.
In fact, if you want to just kind of wade in, rather than jump, go to the
"Issues" on the project home page (subversion.tigris.org) and search for the
"bite-sized" tasks. Those are things that we've estimated to be relative
easy for somebody to do, and are a good way to get acquainted with a section
of the code.
> 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.
Based on this, it seems that you never even looked at that file, yet you're
raising a fuss about things being difficult. Please review the file and then
let us know your thoughts. That would be helpful for us, and for people who
will come along later.
> > 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.
We try. We have the HACKING document to let you know what our basic
guidelines are for building, for coding, for providing patches, etc. That is
the intro piece if you're thinking about contributing.
If you think it is difficult, then let us know. But read that before making
> 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?
Subversion does not have anything like that. We assume the person will use
"svn mv" if they're going to move a file. IOW, yes: you must let Subversion
know about the move.
For many file types, you cannot insert strings like that. Thus, it isn't a
generally reliable way to track unreported movement of files.
It is certainly an interesting feature. Personally, I'd do something like
$ svn watermark foo.c bar.h
Subversion would then insert a UUID into the files, then store that UUID in
the .svn/entries file. Whenever we see an unversioned file, then we look for
a UUID and then scan the entries file to see what the file might be.
However, it is very easy to get into trouble with it. What if you've added
the file under a different name, but didn't remove the watermark? If the
file is moved to an entirely different directory, then how do you find the
.svn/entries that has the watermark info? etc.
> *** "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".
You think so not us or other think in that way.
Seriously, there are hundreds of thousands of CVS users and they don't have
distributed repositories. Certainly all of those people cannot be wrong.
Maybe they would *like* a distributed repos, but it certainly isn't a
requirement if they end up using CVS.
Seriously, we do think it is a nice feature, but we do not see it as a
requirement for our 1.0 release. Our primary goal right now is to replace
CVS. To that end, we only need to match CVS's features, and then be better
enough to make people want to switch. We are already *so* much better than
CVS, that we're quite confident people will like SVN and watch to switch
away from CVS. We don't need distributed repositories to do that.
> 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.
It *is* a good idea, and a nice feature, but it can wait until later.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:56 2006