David Waite and John Peacock discussed ambiguity related to mixed
revision working copys.
My proposal was and still is to simply fill in "mixed" or min:max
("100:200") in the event that a mixed revision working copy is
encountered.
People that deliberately use mixed revision working copys are not the
target audience for the feature anyway, so let's not discuss that
anymore if we can do without :-).
John Peacock further argued that the feature is impossible to
implement and that no-one would ever use it. I've already told a bit
about why I think that $UpdateRev$ would be a über cool feature, so
I'm not going to argue much more about that at the moment.
John Peacock further argued that the problem solved is not really a
big burden for anyone. I disagree - the way I see it, build
environments has to be tweaked and adapted into infinity whenever you
create a new project, start something in a new programming language or
want to put a new type of file in the repository. Plus there's the
costs associated with educating developers, which I could personally
live without. Plus I like the niceties of a platform and
build-environment independent solution, done using the same mechanism
that other Subversion keywords use, instead of various inferior custom
solutions. I'm Not going to enter into any more discussions about
this point either, if I can be without :-).
John Peacock wrote:
> If, instead, your description field contained the tag that the
> application was built off of, you would always be able to recreate any
> release.
Copy/pasting that release number from a tag name into the various source files
where it 'belongs' is one of the processes that I would be happy to be without.
I'll give you an example of where your approach is wrong.
The MyODBC project has in their last 2 or 3 (can't remember) official
releases had the wrong version number in their released DLLs. Some of
their releases even sported
the correct version number in some places, and the wrong one in other.
Automating that process using keywords would be a handy way of getting
rid of that problem altogether. That's a major point in using
keywords _at all_.
Granted, I can do 'svn info | grep URL: | awk -F/ '{print $NF'}' and
somehow stuff that into a file that will get compiled in. That
suffers from a lot of the same problems already mentioned for other
non-keyword-based proposals, and furthermore it doesn't work for
people releasing off trunk - think nightlies and the like.
> > > 1) Branch for the release, complete testing and any integration
> > > to the branch until ready to release.
> > >
> > > 2) Tag the branch and release off the tag, using a tag name
> > > which corresponds to the externally visible package name.
> >
> > That's highly impractical for small projects or
> > projects that are released often.
>
> I strongly disagree. Even if you don't have a firm testing scheme (and
> you should), you can easily skip step 1 and just tag/switch/release.
Oh, ok. Misunderstanding. In that case, that's exactly what we currently do.
Greg Hudson wrote:
[ snipped: clear thinking wrt performance issues ]
> The new keyword value would remain accurate: it would reflect the
> working copy revision of that file. It might not reflect the uniform
> revision of the entire working copy, but we don't have to make that a
> requirement. (Although a name like $GlobalRev$ would probably be a poor
> choice. $WCRev$ would be accurate but still easy to misinterpret;
Right. Agreed.
> $UpdateRev$ is inelegant but makes a certain amount of sense.
> There are probably better choices I haven't thought of.)
Related to that, I'd like to point out an ambiguity (the only one, as I see it).
I was thinking that svn commit should also expand $UpdateRev$,
consistent with what's currently done. Consider however the case
where svn commit is executed on a whole directory. File ABC has
changed, file XYZ contains the $UpdateRev$ keyword. The user will
only be presented with the file that has changes, but to be consistent
with 'svn update', we might want to expand the keywords in the
non-changed file, since the 'commit' action was performed on the
folder containing both items.
I'm not sure how to solve that. One way is to not expand keywords in
the non-changed files, which seems inconsistent with what the user
actually asked for, but might be more in line with what the user
*expects* to happen. Hmm.
Expanding keywords in non-changed files, OTOH, at first seems like a
bad idea, as there is no feedback to the user telling h(im/er) that
any changes was done related to that file.
Thinking a bit more about it, though, the idea becomes a lot more
appealing. Feedback should just be added, but it would be a rather
large alteration of the meaning of 'svn commit' output to call it 'M'
for file modifications. A new flag 'K' could be added to the output,
meaning "you asked to commit this file; it had no changes but we
expanded it's working copy related keywords".
Thoughts?
Marc Sherman wrote:
> Should a file with this keyword in it automatically get modified
> locally every time it's updated, even if there are no remote changes?
If it's included as a target of the update, yes, certainly.
> Should all files be scanned for this keyword so that update knows
> to hit them in this unusual way, or should there be an svn property
> that controls this?
It should of course be controlled by the svn:keywords property, just
like other keywords.
> What happens when there's a commit in the working copy; should this file
> be updated by svn commit as well as svn update?
That already happens as it is now. I have no plans of changing that.
(Actually, you are prevented from committing a file it you have not
updated to it's last committed revision in the repository.)
> What happens if the commit is in a non-local part of the working copy
> (ie: the magic property is in ...wc/foo/bar/magic.txt, and there's an
> svn commit in ...wc/baz/)?
If you svn commit '/wc/baz/', keywords do not get updated in '/wc/foo/'.
Greg Hudson wrote:
> Max was operating on the assumption that "svn update onefile" would have
> to do additional work because he was imagining a keyword whose value
> reflected the state of the entire wc at all times. I don't think users
> are asking for that level of assurance.
For the record, I agree completely.
In our projects, we have no need for that.
John Peacock wrote:
> It's hard enough to convince
> people that keywords are bound to files, and hence only get updated when
> that file gets updated. Once you give them access to a global status
> keyword, the inevitable next question is "Why can't I get that file
> updated automatically in all files that have it?"
The answer to that question is hopefully the same in both cases.
"Files that you target with a 'svn' operation will be modified, others
we leave alone."
> All you have to do is look at the number of questions on the users list
> about why $Revision$ doesn't get globally updated (since many people
> initially believe that to be the repository rev not the file rev).
Those people are probably most confused about how stupid the
$Revision$ keyword seems once they find out what it does. From a
usability, not a technical POV that is. Telling them that there's
actually something that does what they want, which is $UpdateRev$,
would be great.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 4 14:02:49 2005