Dirk wrote:
Hi,
last weekend I thought about correctly handling renames in the case of
pinned shares. VSS performs renames on every share of the item,
regardless whether it is pinned or not. We used the share+pin method
to generate our release maintenance folders and labeled the releases.
So if a rename is done on the original tip project, the release
projects are broken, since the pinned shares are renamed also. My
understanding of a pin is, that it pins the file into the state that
it had while it was pinned. This includes the name and not only the
content. For the conversion it wouldn't be any problem to omit renames
on pinned shares. But this will brake the comparability of the
subversion archive and the last version in VSS after the conversion.
So I'm thinking of a flag to tell vss2svn to do it the correct way.
Any ideas on this?
I was following up until you say it would break compatibility of the
subversion archive and VSS after the conversion. It sounds like the
functionality you describe is the "correct" way (meaning the way VSS
does it) so how would this break compatibility?
I think one general switch indicating whether or not pins should be
honored would be correct. If pins aren't honored then commits are always
done to all items, but otherwise those commits are suppressed, right?
The big problem is that a pin in VSS doesn't really mean anything until
you check *out* an item. So if we honor pins in the converter, then the
user must know that their converted repo will not be in the sort of
state where those pinned items can actually be used for anything besides
checkout.
_______________________________________________
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
