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

Re: Working path created but not repository

From: Ben Kucenski <kalvinb602_at_hotmail.com>
Date: 2004-06-15 04:21:50 CEST

I'll post a full transcript tommorrow showing what works and what breaks.
Since subversion only deals with the database (what I call meta data) that
eliminates one red herring I was chasing.

As far as directories go, since you "add" a directory I refer to getting rid
of directories as "removing" them. And that's where I'm going with this
topic.

Ben

----- Original Message -----
From: "Ben Collins-Sussman" <sussman@collab.net>
To: "Ben Kucenski" <kalvinb602@hotmail.com>
Cc: <users@subversion.tigris.org>
Sent: Monday, June 14, 2004 6:29 PM
Subject: Re: Working path created but not repository

> On Mon, 2004-06-14 at 18:31, Ben Kucenski wrote:
> > I assumed that Subversion kept a copy of all the most current files in
> > browsable format and didn't just store the meta data (the file and
history
> > information) in non browsable format.
>
> I think you're really confused about how subversion works. Let me spell
> it out for you:
>
> The subversion repository has NO files or directories in it. At
> least, nothing vaguely similar to the things you "commit" into it. It's
> just a bunch of database tables that contain *abstract* representations
> of trees. It isn't until you do a 'checkout' that the imaginary trees
> in the repository database are manifested as "real" files and folders in
> a working copy.
>
> Likewise, when you create a directory, 'svn add', then 'svn commit'
> it, all you're doing is add another row or two to some table in the
> repository. It's not real. It's only real in your working copy.
>
> The only thing that's "browseable" is your working copy. The
> repository is only "browseable" via special programs that interpret the
> database. These same special programs also understand how to pull
> history information from the database.
>
> >
> > I gave you the transcript in the first post.
>
> All you showed us was 'svn add'ing a directory, and committing that
> change. How is that useful to us?
>
>
> > The only other thing I could
> > show you is a screenshot of Windows Explorer showing files and folders
in
> > the working copy that aren't mirrored in the repository.
>
> Again, if you look in the repository, you won't see anything but some
> database files. No matter how much you "commit" into it, you won't ever
> see anything resembling your files and dirs.
>
>
> >
> > If it is the case that Subversion only stores information in database
format
> > once the intial collection of meta data is created then my other
question is
> > why can't I remove parent directories which have contained files or
folders
> > in them?
>
> Now it sounds like you're onto a different problem. What do you mean by
> "remove"? Do you mean "delete a folder with windows explorer"? Or do
> you mean issuing the "svn delete" command on a folder?
>
> >
> > If I create an empty directory, commit it and then remove it, it's fine.
If
> > I create an empty directory, commit it, add a file and commit it and
then
> > try to remove the folder it refuses to commit. Even if I remove the
file
> > from it first and successfully commit it.
>
> You're describing a specific series of experiments here. But your
> language is ambiguous. What do you mean by "remove"? How exactly does
> svn "refuse to commit"? Show us a *transcript* of you trying to do this
> stuff in this paragraph. Stop making us guess.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jun 15 04:26:38 2004

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.