You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Hal Vaughan <ha...@thresholddigital.com> on 2005/11/29 18:56:41 UTC
Cannot Checkout or Commit on New Repository
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"
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
Which lead to this:
[hal@server:threshNet]$ svn checkout bin/t-test
checkout (co): Check out a working copy from a repository.
usage: checkout URL... [PATH]...{followed by long help message}
And then (2 more attempts):
[hal@server:threshNet]$ svn checkout
file:///thresh/threshNet/source/bin/t-test
svn: URL 'file:///thresh/threshNet/source/bin/t-test' refers to a file, not a
directory
[hal@server:threshNet]$ svn checkout file:///thresh/threshNet/source/bin/
svn: Failed to add file 'bin/t-test': object of the same name already exists
While trying this, I was looking at the examples in the book. As best I can
tell, I'm doing what I should be doing, but I'm not able to check files in or
out.
As I mentioned, version control is new to me, and it's taking me time to get
used to how Subversion "thinks", so I'm betting I'm missing something really
obvious that I just don't follow. I'm a self-taught programmer (after losing
a job in video, there were no jobs around, and the only opportunity was to
start a business based on programming, which I hadn't done in 10 years), so I
often miss general concepts that most programmers learn in classes.
So what am I doing wrong and what do I need to do if I want to be able to edit
a file and check it in or out of the repository?
Thanks!
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Cannot Checkout or Commit on New Repository
Posted by Hal Vaughan <ha...@thresholddigital.com>.
On Wednesday 30 November 2005 04:55 pm, Ryan Schmidt wrote:
> What I mean to say is that, while you needn't think about buying more
> hardware, you should think about ways to make the existing hardware
> work better for you. Editing the live code as a means of development
> is just not a great plan, and I'm sure you realize that. Perhaps
> you've already run into some problems as a result of this development
> method. As a first step, I could suggest that you have two working
> copies—one for your development work and one for the production site.
> Configure the existing Apache vhost to point at the production
> working copy and configure a new vhost pointing at the development
> working copy. Then you can work in the development working copy,
> making changes, adding new features, and checking your work on the
> stage vhost, and when you're done, you can commit it to the
> repository and then update the production working copy to push the
> change live.
Again, that's part of the problem -- running 2 systems separately is not
affordable. Which leaves me back to editing code directly on the production
system. Since most code interacts directly with MySQL, and since I've got
all the memory I can afford for now, I can't run 2 instances of MySQL on the
system (and, if I did, it'd be a true pain to keep separate the different
ports for communication for test programs and live programs). I've got one
computer with the equipment needed for the system. To NOT edit live code
would mean setting up a sister system, since any programs, even if in
different directories, would still act on the same data and settings and
still interact with the same database.
I had a point, for a couple months, where I had an old server still running
and I was working on the new one. I could only run certain tests on the new
one for 2 (or fewer) days a week because the old server, which was still in
production, needed all the resources. It was an exhausting cycle of write,
predict, be ready, then 1 or 2 days of testing all day and most of the night,
so I could bust my butt for the next 5-6 days preparing for the next test --
knowing full well that if some parts weren't ready, it'd be a week before I
could test them again. I had to keep switching settings, phone lines, data
updates, and other things and it basically exhausted me. I went through days
where I had to have friends drive me to meetings or for errands because I was
no longer alert enough to drive safely.
If, and that is a big *IF*, I had know about Subversion, or even understood
the concept of any kind of versioning programming a few years ago, when this
started, I could have designed around it, and you have some good points,
which I really wish I could do. At this point, I've been on this for almost 4
years of programming, and expect to finish in 6 months.
I've got a great track record for not needing bug fixes. (For example, the
first version of the program that ran on my earlier server was written in a
hurry, so it could gather data while I did the programming, and I intended to
replace it later, after I knew what I was doing. It was my first program in
Perl, and a revision of the first program I had written after not touching a
line of code in over a decade. Once I got it up, it took 2-3 cycles to make
sure it was working right, and it ran perfectly, until I replaced it with a
program including multiple redundancies and error checking over a year later.
When I first learned Java, it was to write the program that my clients run on
their computers. I had never written a program for someone else to run
before. the first version I wrote has been online, in daily use by my
clients, for over 1 1/2 years. We found 4-5 bugs within the first 2 weeks,
and one since then.)
Since I expect to be done in about 6 months, and am exhausted, I am not making
any major changes in the setup at this point. When I'm done programming, a
friend who is helping me (unpaid) and I can add a number of clients who are
waiting for me now. Then I can hire a programmer, build a ghost system, and
let him use Subversion and solve this (and a few other issues) for me. I
know this sounds really PHB-like, but now that the new server is working, my
main purpose for version control is on the revisions of the client program --
however, I figured including the server with that, so I can track which
revisions on the server work with which revisions on the client program,
would make life easier.
> > 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.
>
> One of the nice things Subversion gives you is that you don't have to
> worry about what files you need to copy to get the site up-to-date.
> If the site is in the repository, a simple "svn up" will update a
> working copy to that state. Doesn't matter if your development occurs
> in a second working copy right beside the production one or on your
> home PC. As long as you've committed your changes to the repository,
> "svn up" will know what to update. And should you ever split the
> system into two servers, it's exactly as easy, assuming both machines
> retain access to the same repository.
I also got another reply, with a link to an example of backing up your /etc
directory, so you can easily update, commit, or checkout only what you need.
I know the terms are different, but the effect is close to the same. At this
point, I'm wondering if Subversion is really necessary to my server software
and if I wouldn't find it easier to use it only for the client program. I am
able to have a working and test copy of the client program and keep those
separate rather easily.
> As to databases, our systems are also heavily database-based (over
> 1GB of data in over 300 tables, which seems large enough to me). On
> the production server, we have separate databases for production,
> stage and training, to keep those environments separate, but on the
> development server, all 10 developers share a single development
> database instance. If setting up a second database for development is
> too cumbersome, and if critical changes in the database are rare, you
> can probably get away with a single database for both working copies.
> But obviously if you go and rename a field in the database as a part
> of your development effort, then the production site will have
> problems until you get that code change into the production environment.
Yes, you are right. Which is why I tested the hell out of this before it went
live. I work on a weekly cycle (used to be a 1-2 day cycle for data
gathering and sending it to clients), so, toward the end of testing, I was
able to run what amounted to a 1 week cycle in a day, so I could simulate 2
weeks of data gathering in the 2 days I had to test it. I made sure it was
all well behaved before I switched to the new system -- and then had the
indescribable pleasure of having to patch the code in real time for the 6-8
bugs that showed up after that.
> > 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.
>
> Definitely. And of course you have to weigh the pros and cons and
> decide for yourself. For us the biggest problem with our web sites
> was the many places where files could be uploaded. If we had an image
> database, then we likely had an htdocs directory, inside that an img
> directory containing buttons and headers and other static site
> graphics, and then a imagedb directory inside that with uploaded
> images and their thumbnails, probably named with the ID of a
> corresponding record in some database table. This haphazard mixing of
> the system's code with its data has been the most difficult part of
> switching to Subversion, but in our new projects, and in the old ones
> that we've converted, we now keep all code in the working copy /
> repository and keep all data which can be manipulated by the site in
> directories completely outside the working copy.
Interesting. One issue I had early on was a similar mix of code and data. It
drove me nuts until I decided that certain things, like ANY images, went in
the images directory. There could be subdirectories, but they HAD to go in
there, so I didn't go batty trying to track all files of one type down. It
really helped my sanity -- but I'm also NOT working on a system spread out
over a number of computers. It's just on my server (originally, I had to
develop the database on one and the program on another, so, for a while, it
spanned 2 systems, but I hated that -- if the database went down, the server
was left SOL).
> We've been using
> Subversion for almost a year, and I'd say we're now fluent in and
> quite comfortable with the system. Even our junior programmers are
> flying through the TortoiseSVN menus, merging changes to a branch,
> undoing changes with reverse-merges, making tags, and updating the
> production systems by updating their working copies (basically). It's
> taken some time, but for us it has been worth it.
I'm sure if I were going to continue, it would be worth it. The long and
short is that in June of 2001 I lost my job, there was no job market for my
field here, so I jumped in to start a business. The nature of the business
changed a few times, and when a lawyer/friend told me he needed certain data,
even though I hadn't programmed in years, I jumped on it. I am a writer,
first, last, and always. (I even came damned close to selling to Star Trek
at one point.) My goal is to finish this data gathering system, which is
sold on a monthly subscription basis, and use the income to give me time to
write, THEN to be able to pay for the equipment, cast, and crew to make my
own movies. I'm going this far off topic to make a point: I've been on this
program since Feb of 2002, when the chance came up. I had to work 16 hours a
day for a long stretch just to get to the point where I could stop charging
my life on credit cards. I'm tired of this, and I'm eager to finish my part
so I can focus on adding more clients, increasing the income, and hiring
someone who has been trained to do what I've had to do for the past 4 years.
I have a few standing rules: use FOSS whenever possible, write solid code and
get it done right instead of meeting a deadline with thousands of bugs, and a
few other odds and ends. Otherwise, when I hire a trained programmer, I'll
let him or her make changes that work. Until then, I just want to finish it
without making a mess.
> Just the fact that
> multiple developers can work on multiple tasks without stepping on
> each others' toes is the biggest relief for us (realizing that that's
> not important for your situation). And the ability to track when a
> change was made, and more importantly why, has already helped us
> solve countless problems, not to mention prove to our customer that
> yes, the reason that a change was made was that they did in fact ask
> us to make it. :-)
It's the change tracking that I think will help -- and being able to roll back
to the same version of software a customer has. (Although one thing I've
created is an auto-updating system. I track MD5 sums of all files on a
clients system when logs are sent back, and any time a file is outdated, an
up to date version will be sent out automatically.)
> > 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.
>
> If you have a system that works, by all means, keep it. I don't use
> an IDE either; I get my famously with just a free programming text
> editor. The Subversion GUIs I've found so far haven't seemed easy to
> me either, so I've kept to the command line, which works for me,
> which is what it's all about in the end. As to whether or not you
> need a version control system like Subversion, only you can answer
> that. But if you've recognized that you want to keep better track of
> what you change, and make sure only good code goes to the production
> system, Subversion is a great way to help get that.
I'm glad to hear I'm not the only one who avoids an IDE. I use Kate, part of
KDE on Linux. It's a text editor, with the files it has loaded listed on the
left, and a console at the bottom, so I have the editor and a term to test it
in all together in one window. Whenever I've tried to add more, I find I'm
too busy thinking about the tools than the work.
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Cannot Checkout or Commit on New Repository
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 30, 2005, at 21:10, Hal Vaughan wrote:
>> 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.
Your original goal of keeping everything under /thresh/threshNet
remains met, so I had thought that, if your backup script(s) back up /
thresh/threshNet that they would thus not need to be modified.
> 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.
Having a single server doesn't need to be a problem. While we do have
two servers, one for development work and one for the production
site, we have a few more developers than you do, and the single
development server is happily accomodating 10 developers
simultaneously working on multiple working copies (which are all
stored on the same server and accessed via Samba shares). The
production server not only houses the production site, but also a
staging environment where we put new versions of code for customer
approval and a training environment where the customer can teach new
employees how to use the tool.
What I mean to say is that, while you needn't think about buying more
hardware, you should think about ways to make the existing hardware
work better for you. Editing the live code as a means of development
is just not a great plan, and I'm sure you realize that. Perhaps
you've already run into some problems as a result of this development
method. As a first step, I could suggest that you have two working
copies—one for your development work and one for the production site.
Configure the existing Apache vhost to point at the production
working copy and configure a new vhost pointing at the development
working copy. Then you can work in the development working copy,
making changes, adding new features, and checking your work on the
stage vhost, and when you're done, you can commit it to the
repository and then update the production working copy to push the
change live.
> 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.
One of the nice things Subversion gives you is that you don't have to
worry about what files you need to copy to get the site up-to-date.
If the site is in the repository, a simple "svn up" will update a
working copy to that state. Doesn't matter if your development occurs
in a second working copy right beside the production one or on your
home PC. As long as you've committed your changes to the repository,
"svn up" will know what to update. And should you ever split the
system into two servers, it's exactly as easy, assuming both machines
retain access to the same repository.
As to databases, our systems are also heavily database-based (over
1GB of data in over 300 tables, which seems large enough to me). On
the production server, we have separate databases for production,
stage and training, to keep those environments separate, but on the
development server, all 10 developers share a single development
database instance. If setting up a second database for development is
too cumbersome, and if critical changes in the database are rare, you
can probably get away with a single database for both working copies.
But obviously if you go and rename a field in the database as a part
of your development effort, then the production site will have
problems until you get that code change into the production environment.
> 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.
Definitely. And of course you have to weigh the pros and cons and
decide for yourself. For us the biggest problem with our web sites
was the many places where files could be uploaded. If we had an image
database, then we likely had an htdocs directory, inside that an img
directory containing buttons and headers and other static site
graphics, and then a imagedb directory inside that with uploaded
images and their thumbnails, probably named with the ID of a
corresponding record in some database table. This haphazard mixing of
the system's code with its data has been the most difficult part of
switching to Subversion, but in our new projects, and in the old ones
that we've converted, we now keep all code in the working copy /
repository and keep all data which can be manipulated by the site in
directories completely outside the working copy. We've been using
Subversion for almost a year, and I'd say we're now fluent in and
quite comfortable with the system. Even our junior programmers are
flying through the TortoiseSVN menus, merging changes to a branch,
undoing changes with reverse-merges, making tags, and updating the
production systems by updating their working copies (basically). It's
taken some time, but for us it has been worth it. Just the fact that
multiple developers can work on multiple tasks without stepping on
each others' toes is the biggest relief for us (realizing that that's
not important for your situation). And the ability to track when a
change was made, and more importantly why, has already helped us
solve countless problems, not to mention prove to our customer that
yes, the reason that a change was made was that they did in fact ask
us to make it. :-)
> 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.
If you have a system that works, by all means, keep it. I don't use
an IDE either; I get my famously with just a free programming text
editor. The Subversion GUIs I've found so far haven't seemed easy to
me either, so I've kept to the command line, which works for me,
which is what it's all about in the end. As to whether or not you
need a version control system like Subversion, only you can answer
that. But if you've recognized that you want to keep better track of
what you change, and make sure only good code goes to the production
system, Subversion is a great way to help get that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Cannot Checkout or Commit on New Repository
Posted by Hal Vaughan <ha...@thresholddigital.com>.
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
Re: Cannot Checkout or Commit on New Repository
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.
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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Cannot Checkout or Commit on New Repository
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Nov 29, 2005 at 02:22:11PM -0500, Hal Vaughan wrote:
> So if I want to check out files in a directory, I'd have to delete all the
> corresponding files in that directory, first? Is that correct?
Or checkout into a new directory. Your problem is that you had a full
directory structure, then tried to checkout the same structure in place, so it
sees a bunch of files that already exist and things don't work. If you want
to keep the same path on disk, but have it be in a working copy, yes, either
delete or move aside the current data, checkout into the same path, and go
from there.
> So what do I do after I've edited a file in the bin directory and want to
> commit the changes in that file to the repository?
If it's in a working copy, you can just "svn commit" the change. If it's not,
you have to copy the changes to a working copy and then commit it.
--
Randomly Generated Tagline:
Even dead fish can swim down stream.
Re: Cannot Checkout or Commit on New Repository
Posted by Hal Vaughan <ha...@thresholddigital.com>.
On Tuesday 29 November 2005 02:01 pm, Theo Van Dinter wrote:
> On Tue, Nov 29, 2005 at 01:56:41PM -0500, Hal Vaughan wrote:
> > svn import ./ file:///thresh/threshNet/source -m "Initial import"
> >
> > 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
>
> I don't believe import makes a working copy out of a directory.
>
> > Which lead to this:
> > [hal@server:threshNet]$ svn checkout bin/t-test
> > checkout (co): Check out a working copy from a repository.
> > usage: checkout URL... [PATH]...{followed by long help message}
>
> You can't checkout a file, you have to checkout a directory.
>
> > [hal@server:threshNet]$ svn checkout
> > file:///thresh/threshNet/source/bin/t-test
> > svn: URL 'file:///thresh/threshNet/source/bin/t-test' refers to a file,
> > not a directory
> > [hal@server:threshNet]$ svn checkout file:///thresh/threshNet/source/bin/
> > svn: Failed to add file 'bin/t-test': object of the same name already
> > exists
>
> You can't checkout over the directory you just imported. Either move to a
> new directory, or remove the files you're trying to checkout.
So if I want to check out files in a directory, I'd have to delete all the
corresponding files in that directory, first? Is that correct?
So what do I do after I've edited a file in the bin directory and want to
commit the changes in that file to the repository?
Thanks!
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Cannot Checkout or Commit on New Repository
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Nov 29, 2005 at 01:56:41PM -0500, Hal Vaughan wrote:
> svn import ./ file:///thresh/threshNet/source -m "Initial import"
>
> 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
I don't believe import makes a working copy out of a directory.
> Which lead to this:
> [hal@server:threshNet]$ svn checkout bin/t-test
> checkout (co): Check out a working copy from a repository.
> usage: checkout URL... [PATH]...{followed by long help message}
You can't checkout a file, you have to checkout a directory.
> [hal@server:threshNet]$ svn checkout
> file:///thresh/threshNet/source/bin/t-test
> svn: URL 'file:///thresh/threshNet/source/bin/t-test' refers to a file, not a
> directory
> [hal@server:threshNet]$ svn checkout file:///thresh/threshNet/source/bin/
> svn: Failed to add file 'bin/t-test': object of the same name already exists
You can't checkout over the directory you just imported. Either move to a new
directory, or remove the files you're trying to checkout.
--
Randomly Generated Tagline:
"EE good." - Prof. Vaz