You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rich Shepard <rs...@appl-ecosys.com> on 2007/06/04 19:04:59 UTC

Cleaning Up A Mess

  I've been running svn-1.4.0 and upgraded today to -1.4.3 to gain access to
the new svnadmin commands.

   For a number of months I've had one project in the repository, and decided
to add a new project about a month ago. I followed the instructions in Mike
Mason's book, "Pragmatic Version Control Using Subversion," and it seemed to
go well. Except that committed versions continued the numbering of the
original project rather than starting at build 1 for the new project.

   However, one file (schema.sql) is not transmitted to the repository when I
make changes to it. Thinking the file was not added, I tried adding it. Bad
move; it was already there. When I tried deleting the copy, only the working
copy in the local directory was wiped out (but I was able to re-save it from
the open emacs buffer.)

   While I understand the value of having a permanent repository for files
and their deltas, this entire project's repository is FUBAR. I can use 'svn
ls' and see all the files, but I cannot delete unnecessary ones (as I
could/can with the original project in the repository), and when I commit
changes, this one file is just not updated.

   I've read the 1.4 version of the book, looked at the 'svnadmin help dump'
page, and tried to figure out how to fix this mess on my own. Other than
creating a new project in the repository with the current versions of the
files, what can I do?

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Andy Levy <an...@gmail.com>.
On 6/4/07, Rich Shepard <rs...@appl-ecosys.com> wrote:
> On Mon, 4 Jun 2007, Thomas Harold wrote:
>
> > Good book.
>
>    Thanks, Thomas. I find it quite useful.
>
> > All projects within a repository share revision #s.  So, if you wanted the
> > new project to have its own set of revision #s, you'd need to put it in a
> > repository by itself.
>
>    Oh, well. That's OK by me. I don't understand the logic behind that, but I
> can certainly live with it.

If you're reading the 2005 edition of the book, have a look at page 16
(it may be the same page in other editions, but that's what I have
here). The repository-wide revision numbering is explained there.

If the revision # is that critical to you (and it shouldn't be - only
think of it as shorthand for a date/time stamp), then you'll have to
set up a repository for each project.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Mon, 4 Jun 2007, Thomas Harold wrote:

> Good book.

   Thanks, Thomas. I find it quite useful.

> All projects within a repository share revision #s.  So, if you wanted the
> new project to have its own set of revision #s, you'd need to put it in a
> repository by itself.

   Oh, well. That's OK by me. I don't understand the logic behind that, but I
can certainly live with it.

> I'm not sure on the rest of your question though...

   And that's the really important part.

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Thomas Harold <tg...@tgharold.com>.
Rich Shepard wrote:
> I've been running svn-1.4.0 and upgraded today to -1.4.3 to gain 
> access to the new svnadmin commands.
> 
> For a number of months I've had one project in the repository, and 
> decided to add a new project about a month ago. I followed the
> instructions in Mike Mason's book, "Pragmatic Version Control Using
> Subversion," and it seemed to go well. Except that committed versions
> continued the numbering of the original project rather than starting
> at build 1 for the new project.

Good book.

All projects within a repository share revision #s.  So, if you wanted
the new project to have its own set of revision #s, you'd need to put it
in a repository by itself.

I'm not sure on the rest of your question though...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Mon, 4 Jun 2007, Andy Levy wrote:

> Is it possible that you had a version of the WC, created your own
> schema.sql in it, then updated?

Andy,

   Not likely. I created the files in the cwd, then inserted them in the new
repository's new project.

> The repository clearly thinks that there's already a schema.sql that
> should be there. What if you rename the one you have (not via svn, just mv
> schema.sql myschema.sql) and then update?

   It cleans up the mess. I had to revert the add, then update again. But,
there's now a copy of schema.sql in the WC that makes svn happy. I copied
the backed up current version to the original name, made a meaningless
edit, then commited the change. This time it worked.

Thank you very much,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Andy Levy <an...@gmail.com>.
On 6/4/07, Rich Shepard <rs...@appl-ecosys.com> wrote:
> On Mon, 4 Jun 2007, Andy Levy wrote:
>
> > If svn st is a "new" command to you, I suggest you read further in your
> > book. It's a pretty important one to know & use.
>
> Andy,
>
>    Had not needed it before with the one project. That's worked just fine
> since I set up the repository and installed that project in it.
>
> > For whatever reason, your WC thinks that schema.sql isn't in the
> > repository. If svn add schema.sql doesn't let you add it, something's
> > seriously hosed. What do you get when you try it?
>
>    It tells me that it already exists and cannot be added:
>
> [rshepard@salmo /data1/permitwatch]$ svn add schema.sql
> A         schema.sql
> [rshepard@salmo /data1/permitwatch]$ svn update
> svn: Failed to add file 'schema.sql': object of the same name already exists
>
>    Yes, it is seriously hosed. That's why I ask for help.

Is it possible that you had a version of the WC, created your own
schema.sql in it, then updated?

The repository clearly thinks that there's already a schema.sql that
should be there. What if you rename the one you have (not via svn,
just mv schema.sql myschema.sql) and then update?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Mon, 4 Jun 2007, Andy Levy wrote:

> If svn st is a "new" command to you, I suggest you read further in your
> book. It's a pretty important one to know & use.

Andy,

   Had not needed it before with the one project. That's worked just fine
since I set up the repository and installed that project in it.

> For whatever reason, your WC thinks that schema.sql isn't in the
> repository. If svn add schema.sql doesn't let you add it, something's
> seriously hosed. What do you get when you try it?

   It tells me that it already exists and cannot be added:

[rshepard@salmo /data1/permitwatch]$ svn add schema.sql
A         schema.sql
[rshepard@salmo /data1/permitwatch]$ svn update
svn: Failed to add file 'schema.sql': object of the same name already exists

   Yes, it is seriously hosed. That's why I ask for help.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Andy Levy <an...@gmail.com>.
On 6/4/07, Rich Shepard <rs...@appl-ecosys.com> wrote:
> On Mon, 4 Jun 2007, Andy Levy wrote:
>
> > What does svn st show?
>
> Andy,
>
>    That's a new command for me:

If svn st is a "new" command to you, I suggest you read further in
your book. It's a pretty important one to know & use.

> [rshepard@salmo /data1/permitwatch]$ svn st
> ?      schema.sql
> !      .
> D      reports.txt
>
>    Well, that is certainly not what I expected! According to the status
> report. queries.py is the only file properly registered and current.
>
>    What do you suggest to correct this?

For whatever reason, your WC thinks that schema.sql isn't in the
repository. If svn add schema.sql doesn't let you add it, something's
seriously hosed. What do you get when you try it?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Mon, 4 Jun 2007, Andy Levy wrote:

> What does svn st show?

Andy,

   That's a new command for me:

[rshepard@salmo /data1/permitwatch]$ svn st
?      schema.sql
!      .
D      reports.txt

   Well, that is certainly not what I expected! According to the status
report. queries.py is the only file properly registered and current.

   What do you suggest to correct this?

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Andy Levy <an...@gmail.com>.
On 6/4/07, Rich Shepard <rs...@appl-ecosys.com> wrote:
> On Mon, 4 Jun 2007, Ryan Schmidt wrote:
>
> > Show us the exact commands you enter and the exact results you receive; it's
> > hard to speculate what's going on otherwise.
>
> Ryan,
>
>    Here's the cwd contents:
>
> -rw-r--r-- 1 rshepard users  2743 2007-06-01 17:04 gpmi-data.sql
> -rw-r--r-- 1 rshepard users  6069 2007-05-29 16:57 queries.py
> -rw-r--r-- 1 rshepard users 10451 2007-06-04 10:30 schema.sql
>
>    Here's the current repository contents:
>
> [rshepard@salmo /data1/permitwatch]$ svn ls
> gpmi-data.sql
> queries.py
> reports.txt
> schema.sql
>
>    Now I make minor changes to schema.sql and gpmi-data.sql
>
> -rw-r--r-- 1 rshepard users  2774 2007-06-04 15:37 gpmi-data.sql
> -rw-r--r-- 1 rshepard users  6069 2007-06-04 15:34 queries.py
> -rw-r--r-- 1 rshepard users 10451 2007-06-04 15:36 schema.sql
>
>    Note that emacs changes the mtime of those files.
>
>    Then I commit changes:
>
> [rshepard@salmo /data1/permitwatch]$ svn ci -m "Touched two files."
> Sending        gpmi-data.sql
> Transmitting file data .
> Committed revision 96.
>
>    Why wasn't schema.sql also transmitted? That's what I'm trying to fix.
>
> > One possible reason changes you make to a file aren't seen by Subversion and
> > not transmitted to the repository is if whatever tool you use to edit the
> > file does not bump the file's modification date.
>
>    The only text editors I use are emacs and joe (with the occasional use of
> vi thrown in). They all change the file's mtime when it's modified. I didn't
> know that editors did not do that.
>
> > Telling Subversion to add a file that's already added shouldn't cause
> > anything to blow up; it should just print a message that the file is already
> > added.
>
>    It was the lack of tranmission of changed schema.sql files to the
> repository that made me think it was not properly added.

What does svn st show?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Mon, 4 Jun 2007, Ryan Schmidt wrote:

> Show us the exact commands you enter and the exact results you receive; it's 
> hard to speculate what's going on otherwise.

Ryan,

   Here's the cwd contents:

-rw-r--r-- 1 rshepard users  2743 2007-06-01 17:04 gpmi-data.sql
-rw-r--r-- 1 rshepard users  6069 2007-05-29 16:57 queries.py
-rw-r--r-- 1 rshepard users 10451 2007-06-04 10:30 schema.sql

   Here's the current repository contents:

[rshepard@salmo /data1/permitwatch]$ svn ls
gpmi-data.sql
queries.py
reports.txt
schema.sql

   Now I make minor changes to schema.sql and gpmi-data.sql

-rw-r--r-- 1 rshepard users  2774 2007-06-04 15:37 gpmi-data.sql
-rw-r--r-- 1 rshepard users  6069 2007-06-04 15:34 queries.py
-rw-r--r-- 1 rshepard users 10451 2007-06-04 15:36 schema.sql

   Note that emacs changes the mtime of those files.

   Then I commit changes:

[rshepard@salmo /data1/permitwatch]$ svn ci -m "Touched two files."
Sending        gpmi-data.sql
Transmitting file data .
Committed revision 96.

   Why wasn't schema.sql also transmitted? That's what I'm trying to fix.

> One possible reason changes you make to a file aren't seen by Subversion and 
> not transmitted to the repository is if whatever tool you use to edit the 
> file does not bump the file's modification date.

   The only text editors I use are emacs and joe (with the occasional use of
vi thrown in). They all change the file's mtime when it's modified. I didn't
know that editors did not do that.

> Telling Subversion to add a file that's already added shouldn't cause 
> anything to blow up; it should just print a message that the file is already 
> added.

   It was the lack of tranmission of changed schema.sql files to the
repository that made me think it was not properly added.

   Hope this helps to shed a light on the problem so I can get beyond it.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Cleaning Up A Mess

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 4, 2007, at 14:04, Rich Shepard wrote:

>   I've been running svn-1.4.0 and upgraded today to -1.4.3 to gain  
> access to
> the new svnadmin commands.
>
>   For a number of months I've had one project in the repository,  
> and decided
> to add a new project about a month ago. I followed the instructions  
> in Mike
> Mason's book, "Pragmatic Version Control Using Subversion," and it  
> seemed to
> go well. Except that committed versions continued the numbering of the
> original project rather than starting at build 1 for the new project.
>
>   However, one file (schema.sql) is not transmitted to the  
> repository when I
> make changes to it. Thinking the file was not added, I tried adding  
> it. Bad
> move; it was already there. When I tried deleting the copy, only  
> the working
> copy in the local directory was wiped out (but I was able to re- 
> save it from
> the open emacs buffer.)
>
>   While I understand the value of having a permanent repository for  
> files
> and their deltas, this entire project's repository is FUBAR. I can  
> use 'svn
> ls' and see all the files, but I cannot delete unnecessary ones (as I
> could/can with the original project in the repository), and when I  
> commit
> changes, this one file is just not updated.
>
>   I've read the 1.4 version of the book, looked at the 'svnadmin  
> help dump'
> page, and tried to figure out how to fix this mess on my own. Other  
> than
> creating a new project in the repository with the current versions  
> of the
> files, what can I do?

Show us the exact commands you enter and the exact results you  
receive; it's hard to speculate what's going on otherwise.

One possible reason changes you make to a file aren't seen by  
Subversion and not transmitted to the repository is if whatever tool  
you use to edit the file does not bump the file's modification date.  
If this is the case, instruct the tool you use to edit the files not  
to fudge the modification date like that. If you can't, then remember  
to "touch" the file before trying to commit.

Telling Subversion to add a file that's already added shouldn't cause  
anything to blow up; it should just print a message that the file is  
already added.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org