Those kind of things can be tricky and messy. Something like a
dependency graph would be required, which is all but easy to implement.
It has something to do with how patches are applied with git: order
matters. 'git log --graph --pretty-oneline' displays s a representation
of this order. Git m
Michael Hafen a écrit :
> Calling out to atomic files would be a good idea. It only partially
> alleviates merge conflicts though, because the reference to the file
> still have to appear in updatedatabase.pl. You would end up missing an
> entire update rather than potentially messing up part of
Calling out to atomic files would be a good idea. It only partially
alleviates merge conflicts though, because the reference to the file
still have to appear in updatedatabase.pl. You would end up missing an
entire update rather than potentially messing up part of an update with
a merge conflict.
Michael Hafen a écrit :
> Update order. I hadn't thought of that. That could be a big deal.
>
>
Well it could be important at some point :
you cannot update a field which doesnot exist.
And so on
> I'm already committed to writing it if it does get traction. I have a
> couple database upd
I would have to agree the patch order probably won't be an issue, as
each patch will still be added in the chronological order that it was
committed ( assuming every always adds to the end of the file as usual
).
Kyle
http://www.kylehall.info
Information Technology
Crawford County Federated Libra
Update order. I hadn't thought of that. That could be a big deal.
I'm already committed to writing it if it does get traction. I have a
couple database updates in my own branch that couldn't be in the the
updatedatabase.pl obviously. If this does get traction and we can
figure out the patch or
On Thu, Jan 28, 2010 at 1:04 PM, Kyle Hall wrote:
>> create a syspref (with TEXT, we have a lot of space).
>> Separate each patch applied with a comma :
>>
>> BibLibre-1,mhafenA,someoneElse,anotherone,BibLibre-2, ...
>>
>> need to check that a patch has been applied ? just =~ /BibLibre-1,/ if not
> create a syspref (with TEXT, we have a lot of space).
> Separate each patch applied with a comma :
>
> BibLibre-1,mhafenA,someoneElse,anotherone,BibLibre-2, ...
>
> need to check that a patch has been applied ? just =~ /BibLibre-1,/ if not
> applied, apply it, and add BibLibre-1, at the end of ap
Kyle Hall a écrit :
> The naming convention sounds very reasonable. Very java import styled.
> Very good idea.
>
> Now the big question is, can we get any traction for such a big
> change? Is there anyone else willing to comment on the possbility of
> this idea?
>
create a syspref (with TEXT, we
The naming convention sounds very reasonable. Very java import styled.
Very good idea.
Now the big question is, can we get any traction for such a big
change? Is there anyone else willing to comment on the possbility of
this idea?
Kyle
http://www.kylehall.info
Information Technology
Crawford Cou
Clearing the tracking table isn't necessary. I'm thinking 50 versions
down the road when the tracking table has some 500 strings. This makes
it a little harder to ensure a unique string for the update. And I
would rather the table stay small to be quicker to index and to take up
less space on th
On 28/01/10 14:25, David Schuster wrote:
>
> Anyone else having problems getting into IRC? I was wondering since it was a
> Katipo server if it has been taken down?
>
> Or maybe our tech people figured out a way to block me!
Chris tweeted that the NZ folks could get on but the international link
Join #koha on irc.freenode.net while we wait for the international
connection to irc.katipo.co.nz to come back up.
-- Owen
___
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
Anyone else having problems getting into IRC? I was wondering since it was a
Katipo server if it has been taken down?
Or maybe our tech people figured out a way to block me!
David Schuster
--
View this message in context:
http://old.nabble.com/IRC-connection-problems--tp27356781p27356781.html
I like this idea. I've had a number of problems with the current
system. If I understand correctly, we would need a database table to
track updates. It sounds like we would only need a single column that
would contain the title of the update, say "BugFix2235" for example.
The update script would th
15 matches
Mail list logo
