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 meant, if we do it the VSS way you can compare the archives later, in
order to determine, whether the conversion was successful. Also, at one
day, when someone is writing an incremental version of the converter,
that mirrors a nightly version of a VSS archive into a subversion
archive, the two archives are identical in the way, that if you search
for a file, the file is really there.
Doing it the VSS way will simply give you an subversion project
structure that is identical to the one in VSS.
In this special case I consider this renaming of pinned shares to be the
wrong action, regarding in terms what the user wanted to achieve with
the pinning. Therefore I'm thinking about adding more intelligence into
the converter to fix something, what I consider a bug in VSS. Actually
it is vice versa: I have to put work into the converter to do it the VSS
way.
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.
Hmmm. Naturally pinning is a little problematic concept in a version
control system. But it does not only affect the checkout procedure. You
also can't modify pinned files directly. You need to do it via a non
pinned share. And yes you will see the checkin in the hostory of the
pinned share, but you can't do anything with this new version. It will
not affect you in any way (except renaming ;-) )
Pins are primarily used when creating maintenance branches since they
are "cheap" in the creation of the branch. Seldom I have used pins to
temporarily undo a change from a developer that broke compilation for
others. So a pin in my understanding is: "revert the state of the item
to version X". The way VSS works, there is no way to undo the revert
since reverting (or better Rollback) is an irreversible process.
So I think, there is no need to have a switch to honor pins are not.
They must be honored. The question is wether we allow any modifications
on pinned items (esp. renames) since these actions will modify the
pinned state.
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
