You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by pl...@lanminds.com on 2002/10/09 14:39:37 UTC
Best Practices question
Hi all,
I have a location I want to use for my SVNROOT. The file system is
currently mounted as /spare. I also have several unrelated projects
I'd like to keep under svn. What is the proper/best way to do this?
Do I:
$ mkdir /spare/svn
$ svnadmin create /spare/svn/projA
$ svnadmin create /spare/svn/projB
$ svnadmin create /spare/svn/projC
Or:
$ svnadmin create /spare/svn
$ svn mkdir file:///spare/svn/projA
$ svn mkdir file:///spare/svn/projB
$ svn mkdir file:///spare/svn/projC
I don't fully understand the differences between the two, since I'm
not a revision-control guru (I know rcs better than anything else,
and have barely used CVS in the past, but never administered a
repository of any kind).
Could someone kindly explain to me what the implications of the above
actions are, and maybe why I would choose one over the other? Is it
possible you might want to do the first in some circumstances, but
the second in others?
Thanks,
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Ben Collins <bc...@debian.org>.
> $ mkdir /spare/svn
> $ svnadmin create /spare/svn/projA
> $ svnadmin create /spare/svn/projB
> $ svnadmin create /spare/svn/projC
Unrelated projects should be kept physically seperate.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Paul Lussier <pl...@lanminds.com>.
In a message dated: 09 Oct 2002 16:12:30 CDT
Karl Fogel said:
>Paul Lussier <pl...@lanminds.com> writes:
>> Is this how it is currently maintained? The reason I ask, is FAQs
>> often suffer from lack of updating, and I've found in the past that
>> tools like FAQ-O-Matic help reduce FAQ-rot :)
>
>I've only had experience with a couple of FAQ-O-Matic-ized FAQ
>documents, so maybe I'm speaking from ignorance, but as far as I can
>tell, It Does Not Work.
>
>FAQs are for humans, and need humans to maintain them. Software can
>assist with this, of course, but FAQ-O-Matic doesn't really address
>the problem of assisting a human maintainer(s). Instead, it tries to
>automate and decentralize maintenance. The results are some pretty
>awful FAQs, filled with redundant, out-of-date, and inconsistent
>information (that's three separate sins, yes, and I've seen them all).
>
Well, I guess, in a sense, I agree with you. However, a tool can
only do the job it's meant for if used properly, right? So what
about a moderated/human maintained FAQ-O-Matic? IOW, only certain
people are allowed to update/change the FAQ-O-Matic data.
>Is FAQ-O-Matic really easier than mailing a patch?
Well, IMO, yes, because:
- I don't need to worry about all the html crap
that's in the current FAQ
- I don't need to search through the file to find where the
proper FAQ goes
- There's no redundancy of information
(Currently each question is in the FAQ twice!)
- There's no need for anyone to:
download the svn source
edit the faq
create a diff
mail it in
wait for it to make it into the main faq
The process could be as simple as mailing the FAQ to the dev list and
someone (I volunteer) can just cut'n'paste it into the FAQ-O-Matic.
In general it doesn't much matter to me if the svn team decides to go
this way or not. I can say I'm much less likely to contribute FAQs
with the current scheme just becaue I find it too tedious.
>Just send to dev@subversion.tigris.org. And the first one can be a
>patch about how to add new FAQ items, yes :-).
I have 3 FAQs I've added to the FAQ, I'll send them in :)
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Paul Lussier <pl...@lanminds.com> writes:
> Is this how it is currently maintained? The reason I ask, is FAQs
> often suffer from lack of updating, and I've found in the past that
> tools like FAQ-O-Matic help reduce FAQ-rot :)
I've only had experience with a couple of FAQ-O-Matic-ized FAQ
documents, so maybe I'm speaking from ignorance, but as far as I can
tell, It Does Not Work.
FAQs are for humans, and need humans to maintain them. Software can
assist with this, of course, but FAQ-O-Matic doesn't really address
the problem of assisting a human maintainer(s). Instead, it tries to
automate and decentralize maintenance. The results are some pretty
awful FAQs, filled with redundant, out-of-date, and inconsistent
information (that's three separate sins, yes, and I've seen them all).
Is FAQ-O-Matic really easier than mailing a patch?
> What is the procedure for submitting a patch? Do I just mail it to
> the dev list? Of course, this should be a FAQ itself, shouldn't it :)
Just send to dev@subversion.tigris.org. And the first one can be a
patch about how to add new FAQ items, yes :-).
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Paul Lussier <pl...@lanminds.com>.
In a message dated: 09 Oct 2002 10:54:37 CDT
Ben Collins-Sussman said:
>We already have a FAQ on the website. See the little link up there?
Yep, I saw the link a while ago. Which is why I offered to help
maintain it.
>Submit a patch for it.... it's in our source tree:
>www/project_faq.html.
Is this how it is currently maintained? The reason I ask, is FAQs
often suffer from lack of updating, and I've found in the past that
tools like FAQ-O-Matic help reduce FAQ-rot :)
What is the procedure for submitting a patch? Do I just mail it to
the dev list? Of course, this should be a FAQ itself, shouldn't it :)
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Ben Collins-Sussman <su...@collab.net>.
Paul Lussier <pl...@lanminds.com> writes:
> I'd be more than happy to help maintain an FAQ, especially, since I'm
> bound to be Frequently Asking Questions! I may as well write them
> down, consolidate the replies, and post the answers :)
We already have a FAQ on the website. See the little link up there?
Submit a patch for it.... it's in our source tree:
www/project_faq.html.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Paul Lussier <pl...@lanminds.com>.
In a message dated: 09 Oct 2002 10:16:41 CDT
Ben Collins-Sussman said:
>Man oh man, we need to make this a FAQ, or put it in the handbook.
>People keep asking this. :-)
I'd be more than happy to help maintain an FAQ, especially, since I'm
bound to be Frequently Asking Questions! I may as well write them
down, consolidate the replies, and post the answers :)
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Best Practices question
Posted by Ben Collins-Sussman <su...@collab.net>.
pll@lanminds.com writes:
> $ mkdir /spare/svn
> $ svnadmin create /spare/svn/projA
> $ svnadmin create /spare/svn/projB
> $ svnadmin create /spare/svn/projC
This creates 3 independent repositories. Each project has its own
repository.
> $ svnadmin create /spare/svn
> $ svn mkdir file:///spare/svn/projA
> $ svn mkdir file:///spare/svn/projB
> $ svn mkdir file:///spare/svn/projC
This creates three project subdirectories within a single repository.
> Could someone kindly explain to me what the implications of the above
> actions are, and maybe why I would choose one over the other? Is it
> possible you might want to do the first in some circumstances, but
> the second in others?
Man oh man, we need to make this a FAQ, or put it in the handbook.
People keep asking this. :-)
* In the second case, code can easily be copied or moved around
between projects, and the history is preserved. ('svn cp/mv'
currently only works within a single repository.)
* Because revision numbers are repository-wide, a commit to any
project in the 2nd case causes a global revision bump. So it
might seem a bit odd if somebody has 'projB' checked out, notices
that 10 revisions have happened, but projB hasn't changed at
all. Not a big deal, really. Just a little weird at first.
This already happens to svn, everytime people commit to
rapidsvn. :-)
* The first case might be easier to secure; it's easier to insulate
projects from each other (in terms of users and permissions)
using Apache's access control. In the 2nd case, you'll need a
fancy hook script in the repository that distinguishes projects
("is this user allowed to commit to this particular subdir?") Of
course, we already have such a script, ready for you to use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org