Is there a way to have keywords expanded for existing files?
Moderator: SourceGear
-
Dave Schulte
- Posts: 55
- Joined: Thu Dec 02, 2004 1:59 pm
Is there a way to have keywords expanded for existing files?
Is there a way to have keyword expansion take place after having added a file to Vault while no keyword expansion was defined for a given repository. It seems that if you define keyword expansion after adding a file, you must delete and add the file again to have keyword expansion apply. Is this true, or is there a way to force keyword expansion even for existing files, assuming they have keyword strings in them?
-
Dave Schulte
- Posts: 55
- Joined: Thu Dec 02, 2004 1:59 pm
It's interesting, because it has always seemed to me (when I was considering SourceSafe keyword expansion) that the expansion should happen when getting the file from the source control system. When the file is checked in/updated any expansion text should be removed.
Since the source control system stores all the information needed by the keyword expansion somewhere else anyway, why duplicate it.
In fact it this scheme would let you do a diff of versions of a file and not see the keyword expansion text show up as a change.
I'm wondering if there are reasons that haven't occurred to me not to do keyword expansion this way.
Mike
Since the source control system stores all the information needed by the keyword expansion somewhere else anyway, why duplicate it.
In fact it this scheme would let you do a diff of versions of a file and not see the keyword expansion text show up as a change.
I'm wondering if there are reasons that haven't occurred to me not to do keyword expansion this way.
Mike
-
Dave Schulte
- Posts: 55
- Joined: Thu Dec 02, 2004 1:59 pm
Actually, that is the behavior I would have desired (keyword expansion on get). This is how SCCS works. On checkout, what you see is an unexpanded keyword string, but on get (or copyout) the keyword string is expanded.
I can understand, however, why one might want the keyword string only expanded on add or check-in. If a given file is moved from one folder to another, or the parent folder is renamed, the image currently in vault really should refer to the previous folder, unless an automatic uprevision occurs to update the keyword details.
I can't really make a strong argument either way. Both can make sense depending on how someone expects to use the tool. Where I got burned was in changing our folder structure by renaming and moving folders after having imported a bunch of source. I had to reimport all of the product releases that we had initially imported (luckily we wrote some software to do this automatically, so it was relatively painless). This is just another reason to get your product structure in order before importing.
Maybe it would be useful to give developers the option of having a folder change automatically update (both with and without consuming version numbers) keyword expansions. This would give folks the best of both worlds. Just a thought.
I can understand, however, why one might want the keyword string only expanded on add or check-in. If a given file is moved from one folder to another, or the parent folder is renamed, the image currently in vault really should refer to the previous folder, unless an automatic uprevision occurs to update the keyword details.
I can't really make a strong argument either way. Both can make sense depending on how someone expects to use the tool. Where I got burned was in changing our folder structure by renaming and moving folders after having imported a bunch of source. I had to reimport all of the product releases that we had initially imported (luckily we wrote some software to do this automatically, so it was relatively painless). This is just another reason to get your product structure in order before importing.
Maybe it would be useful to give developers the option of having a folder change automatically update (both with and without consuming version numbers) keyword expansions. This would give folks the best of both worlds. Just a thought.