Dirk wrote:
> potentially harmful - consider:
>
> ADD project1/
> ADD project1/testfile.txt
> ADD project2/
> SHARE project2/testfile.txt (from project1/testfile.txt)
> DELETE project1/testfile.txt
> SHARE project1/testfile.txt (from project2/testfile.txt)
> DELETE project2/
I have to think about this a little further but have to leave for today.
So just a fast question: Do you mean DELETE or PURGE? But it could be
same effect in this case, since a purge of a shared item will not purge
it from the harddisc, as long as there are active shares.
For the testfile.txt delete, this was a "destroy" which translates to
"reduce reference count by 1"
For project2 this was a "destroy" which translates to "obliterate this
item from the disk".
To expand slightly on my "opens yet another can of worms" comment...
If a commit occurs in project2 before the file is shared back, then this
needs more intelligent commit handling... I think at the "No more active
itempath to commit ..." error it should really be creating an orphan
based on the last known revision and the new copy of the file (which
would then leave the "current revision" and its checkin history in a
similar situation to what we would have if the file had originally been
created in project2 and then shared to project1).
I also had a further think, and with a "more intelligent" commit handler
like this, the following additional changes could be made, so that an
item exists in orphaned only if it does not exist elsewhere.
a) SHARE of an orphaned item can become a MOVE instead.
b) BRANCH would not need to immediately create the new orphan but merely
record where the current revision is.
c) file MOVE from an unknown location can become a SHARE (which if the
item is orphaned will turn back into a MOVE again)
d) file MOVE to an unknown location can become a DELETE (modified commit
handler will recover this into orphaned if needed)
e) dir MOVE to/from an unknown location can become a MOVE to/from orphaned
Ref the branch handler... ideally, when (say) BAAAAAAA is branched at
revision 3 to create GAAAAAAA, the internal state tracking GAAAAAAA's
parent paths would inherit BAAAAAAA's up to revision 3. Then if GAAAAAAA
is shared elsewhere and then branched or pinned to revision 1 or 2, it
knows where to get this...
(This actually happened in my VSS database with one file - the PIN to a
revision that does not exist on that physical file is semi-ignored).
--
Stephen Lee <[EMAIL PROTECTED]>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
