[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] jgit timestamp provider ignores local changes
|
On 2013-03-06 5:32 AM, Mickael Istria wrote:
On 03/05/2013 05:10 PM, Igor Fedorenko wrote:
Just to clarify, jgit timestamp for a dirty working tree does not make
sense because it is impossible to know if the changes will be committed
or not. So the patch should fail the build if the working tree is dirty.
The same applies to staged commits, btw.
If you want to test your changes before you commit, you need to switch
to default timestamp provider... or maybe add configuration parameter to
jgit provider to use current time.
Having to choose manually on whether to use commit timestamp or
something else will be for sure a cause of errors.
Maybe it would be possible to make something that provides a more
general stategy to the BuildQualifierMojo? For example, we could think
of a strategy that would use the commit timestamp when working copy is
clean, but that would use <commitTimestamp>-DIRTY when something was
changed locally.
I did not mean to choose manually. I meant always fail jgit timestamp
generation when working tree is dirty and let the user force use of
current time with -D parameter.
I would not use different qualifier strings based on state of working
copy. Qualifiers are compared as strings, I can't recall if longer
string is considered newer or older and I am sure many users will not
know this either. With dirty working tree there isn't really a good
durable timestamp to compare builds with, so we just need to educate
users to be aware of local repository pollution with transient builds.
Also, it would be interesting to have the tycho-p2-plugin able to
compare a bundle with a baseline ignoring the qualifier.
That would allow to just not care about the qualifier, and if everything
else is the same (classes, MANIFEST...) we replace the new one with the
previous one.
For this, the use-case is not "Reproducible Versions Qualifier" but
"Avoid providing always new builds of the same thing".
This approach was considered but rejected. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=367581#c9
WDYT?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
