[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mac OS X - best setup for small developer?

From: Richard Jolly <richardjolly_at_mac.com>
Date: 2005-03-24 18:04:58 CET

 
On Thursday, March 24, 2005, at 04:55AM, Dave Camp <dave@thinbits.com> wrote:

>On Mar 23, 2005, at 2:40 PM, Craig Heilman wrote:
>
>> I'd like to be able to not only have a working copy of the code on the
>> laptop, but also be able to access older versions from the repository.
>> Unfortunately, most clients do not allow "foreign" machines on their
>> networks, so I'd probably need a copy of the repository(s) on the
>> laptop rather than trying to access it via the Internet. When the
>> laptop repository(s) is "active", the desktop repository would not be
>> in use (there's only one of me).

[snip]

Perhaps svk would help you?

http://www.perl.com/pub/a/2004/03/03/svk.html

[snip]

>> (4) Although the "Book" says you can put multiple projects in one
>> repository, is there any advantage to having a repository for each
>> project (most my projects are just text code files)?
>
>I would guess the tradeoff is convenience for sharing files (single
>repository) vs not putting all of your eggs in one basket (multiple
>repositories). If you are storing archives for your clients (i.e. you
>are a consultant or contractor) you might be better off with separate
>repositories to keep their source completely separate.

This is my approach - one repository per client. But I think it really depends on if you are likely to share code/files across clients. Anything thats shared benefits from being in a single repository.

Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 24 18:07:42 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.