Stephen Lee schrieb:
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).
This is indeed a problem and was part of a discussion in prior mailing
also. The problem here is, that we can not "introduce" virtual actions
into the flow of events. E.g. in the ActionHandler we detect the
deletion of the item and we delete it. Later we detect a checkin, but we
don't have an active item path anymore, so we first have to copy the
deleted item into the orphaned cache. This would introduce a new Action
which is currently not possible. The other possibilitiy is to never
delete items, but to move them always into a "_deleted" folder, but this
would clutter the workspace. So you have to choose between pest and
cholera.
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.
OK.
b) BRANCH would not need to immediately create the new orphan but
merely record where the current revision is.
Could be difficult.
c) file MOVE from an unknown location can become a SHARE (which if the
item is orphaned will turn back into a MOVE again)
Ähm, how do we know where to move/share from, if the "source path" is
unknown?
d) file MOVE to an unknown location can become a DELETE (modified
commit handler will recover this into orphaned if needed)
OK.
e) dir MOVE to/from an unknown location can become a MOVE to/from
orphaned
The same problem here: what is the move source if it is unknown?
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 is indeed a problem and I think this could be solved by deep
copying the branch source. I will have a look at this.
Dirk
_______________________________________________
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
