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

FW: Re: log across copies?

From: Labanca, Rick <rick.labanca_at_studentuniverse.com>
Date: 2004-07-30 17:40:24 CEST

-----Original Message-----
From: Labanca, Rick
Sent: Friday, July 30, 2004 11:35 AM
To: 'Ben Collins-Sussman'; Erik Anderson
Cc: users@subversion.tigris.org
Subject: RE: Re: log across copies?

> I absolutely agree with you guys. This is exactly why need
> "real merge
> tracking" in Subversion, or at least one form of it. If the person
> porting the change forgets to write a commit-message that describes
> where the merge came from, then everything falls apart. The system
> should be doing that for us.
> There are some notes on merge-tracking problems here, for
> those curious:

One more comment on this. In that document, it mentions no true rename.
I haven't looked at the schema so I am commenting blind, but that never
stopped me!

It seems the name and dir of the object is somehow important in
identifying an object. Instead of that why not just create object id's
that never change and have the path and name be mere properties of that
object. A rename or move then is just a property change and totally
trackable. So internally when a command refers to a file, it really
would look up and use an oid.

At first I thought svn was like this just in my first hearing of it. It
probably is too radical to change it now. But I think the best approach
to a repository is to make immutable oid's with varying properties
(name, path, content etc). You could even have branched objects be the
same oid by having a versioned "content" property.

Easy to say when you're not having to write all of this!


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 30 17:41:10 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.