Re: Re: log across copies?

> So no, they're not disconnected at all. The connection is only easily
> traceable in one direction, however.
> > And when the object eventually goes back to the trunk, it sounds like
> > there will be a "hole" for all the branch changes?

By this I mean the trunk has a bug in a file. I suspect a change in a line, and I see it between two revs. But inbetween those revs, the file could have been copied to other branches and gone through many revs, and come back. A hole in detail may be a better way to say this.

> Note that this design isn't accidental, nor is it necessarily a design
> flaw; the tradeoff here is that branches and tags can be made in O(1)
> time. It also means that they live in directory space, so they can be
> access-controlled. (And they're easier for SCM newbies to understand.)
>
> I think this will answer a lot of your questions:
>
> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt

I was kind of assuming this was the problem. I'm not sure why making branches very fast is such a high design priority, it never bothered me since making them is not done all that often. But tags==branches so perhaps that's why but I'm willing to wait for tagging too.

Even if it's brute force, this is needed. I see comments in that document that forward pointing was thought of I and I really agree with that.

I mean, it's not just the value of a repository that data isn't easily lost and it has a history, but that the data can be audited to see when things went wrong.

We've got branches all over the place, and we often have to find where a piece of code broke. With subversion it's going to be rough. It sounds like the only option I now have is to browse all the branches I can see, and look at the file logs separately.

Plus if in a branch, the filename changes or the file moves, I'm not sure how to even see that foo.c is really the bar.c I was looking for....

I'm new to this but trying to get up to speed fast for answering dev questions as they convert over.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 22:02:22 2004