On Thu, 2005-12-01 at 16:41 -0500, Peter Amstutz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 30 Nov 2005, Braden McDaniel wrote: > > > Suppose you have a file foo/bar/file. foo/bar/file gets deleted. The > > foo/bar branch becomes foo/baz. Time passes. Maybe foo/baz becomes > > bar/boo. You realize you need file. But you won't be able to retrieve it > > as bar/boo/file--no way. You'll have to remember where it was when it > > you deleted it. > > If this is really the fundamental problem with SVN branching, I guess I > fail to see how this is a problem -- yes, recovering deleted files can be > a pain in the ass, but it's also a pain in the ass with CVS. You need to > know when and where to find the file you're trying to recover anyways, so > why is figuring out the path at that point in time so difficult?
Because all you have to go by is the root-level change log and, if you're lucky, memory. With CVS, you don't change the repository structure to branch. So things stay right where you left them. > Alright, I suppose I could see how this might get tricky if you have a > branch of a branch of a branch, but that would assume development on a lot > of parallel versions. Which, if you're cross-merging, is going to be > sticky any way you do it. There are revision control systems that handle this a lot better than svn. cvs isn't one of them; it's only marginally better in that branches are tags that track a lineage rather than being part of a lineage. > > svn is remarkably little help with things like this. Using the directory > > structure to model branching was simply the Wrong Answer. And I fear svn > > has gone to far down that road to turn back. > > Perhaps I'm just being narrow-minded (in fact I'm sure I am, since I > haven't sat down and tried out any other ways of doing branching) but if > it is the Wrong Answer, perhaps I just don't know what the question is. Well, the question is "How does one best support parallel development?" I don't think there's a conclusive answer to that; but I am confident that a solution that results in fragmented history is out of the running. > The discussion is academic, anyway. At the moment, we arn't using > branching in VOS at all. So some kind of branching, even less than ideal, > is better than none. As for local, client-side versioning, there is SVK > and also "Tailor" that Lalo mentioned, that allow interfacing subversion > with other systems. A project that doesn't have much demand for parallel development will probably not feel cramped by svn's limitations. > I'm supprised this is such a contentious issue. It's almost like we were > discussing which operating system is best or something :-) Let me be clear: I do not have any opinion on the revision control software VOS uses. Choose what *you* think will work for *you* best. I'm just offering my opinion of svn based on three years of use on a fairly large project with a team of 5-8 developers. Your needs may differ. -- Braden McDaniel e-mail: <[EMAIL PROTECTED]> <http://endoframe.com> Jabber: <[EMAIL PROTECTED]> _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
