On Wednesday 30 November 2005 06:19 am, Ryan Schmidt wrote:
> On Nov 29, 2005, at 19:56, Hal Vaughan wrote:
> > I have a system (I've mentioned it before) that I'm developing on
> > Linux. It
> > is all in the directory tree /thresh/threshNet/. In the directory
> > threshNet
> > are a number of subdirectories, some I have set to be ignored, the
> > rest are
> > part of the project. I set this up way before I ever realized I'd
> > be needing
> > version control (actually, before I even really knew what it was --
> > I'd just
> > back up the old version of a file before I started changing it), so
> > the
> > repository is in /thresh/threshNet/source -- and, yes, this
> > directory is set
> > to be ignored.
> >
> > So, while in the /thresh/threshNet/ directory, I ran this:
> >
> > svnadmin create source
> >
> > to create the repository. (Again, I need it in the same tree so
> > it'll be
> > included in backups and archives.) After this, I edited the global
> > config
> > file in /etc/subversion to ignore a number of directories,
> > including source.
> > Then, to enter my project, I did this:
> >
> > svn import ./ file:///thresh/threshNet/source -m "Initial import"
>
> Really not such a great idea to have your repository inside your
> working copy. Working copies are supposed to be just that—copies
> where you work. The fact that it's a copy (of what's in the
> repository) is supposed to mean that you can freely delete the
> working copy at any time, or create new ones for separate tasks. By
> putting your repository inside your working copy you create a
> dangerous confusion.
Yeah, I figured it's not the greatest idea, but moving it involves changing
settings on that machine and the systems (plural!) it backs up to. The other
problem, and I can hear people scream in terror now, is that I'm a small
business and can't afford more computers, so this is the computer the system
actually runs on. I have to edit the code on the working, production model.
The system needs certain databases, as well as expensive modems to work
properly, as well as access to dial-in systems. I simply CANNOT afford one
production system and one "working copy" system. I tried that for several
months and the little things like swapping the phone lines, changing times
when one was allowed online and one wasn't almost drove me insane. It was
also almost impossible to keep them synced in terms of data and needed logs,
since I could not use a scheduled backup like rsync, since it would often
overwrite files I was working with.
It's a small business, I get to finish code when I consider it finished (not
on deadline), and do it my way, but I just don't have the funds and/or time
to do everything the way some would want it done. I have a budget, and it
has to pay for the computers and food and rent and heating... I'm also
working 16-20 hours a day, so taking time to alter my setup for backups so I
can do things Subversion's way is not something I relish doing.
I'm not fighting you -- just pointing out there are many things that can limit
our situations or setups.
> Instead, put your repository in a location of its own, say /thresh/
> threshNet/repository (or "source" if you think that's clearer). Then
> you can make any number of working copies that you like, for example /
> thresh/threshNet/trunk or /thresh/threshNet/new-design or /thresh/
> threshNet/widget-feature. You can make new working copies as needs
> arise and remove the old ones as they're no longer needed.
Actually, that's what I've done. I have /thresh/threshNet/source for SVN,
and /thresh/threshNet/bin (and config, docs, help, data....) for the program.
The source directory is ignored. This way my backup programs get the
repository as well as the entire system in one swell foop.
> > and it imported all my files. Once this was done, I wanted to test
> > it out, so
> > I edited one program, /thresh/threshNet/bin/t-test by changing it
> > just a
> > little, and got this:
> >
> > [hal@server:threshNet]$ svn commit bin/t-test
> > svn: '/thresh/threshNet/bin' is not a working copy
>
> As Theo said, importing a directory into Subversion does not
> transform that directory into a working copy. Theoretically, after
> you import a directory into a repository, you then delete the
> directory and check out a new working copy from the repository. In
> practice you probably want to just move the imported directory aside,
> in case you discover the import went awry and you need to redo it.
> And in your case in particular, since you put the repository into the
> directory you were importing, you certainly cannot delete it or you'd
> delete the repository with it.
I didn't realize or understand this, and it is an issue for me. I'm the only
one working on this, and will likely be the only one working on it until I
can afford employees (at that point I'll have test systems for development
and lots of other "nice" things). I've developed it over several years, as I
learned more about programming (I had a class in Assembler in the 1980s, but
am self taught otherwise). I only recently learned what an IDE is, and am
not using one because it's too damned hard to change everything in my setup,
which works well for me, into what an IDE wants me to have.
I may seriously just drop using Subversion, or use it only for the client
system, which does have a development directory tree and a working tree for
testing.
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 30 21:21:28 2005