See http://bugs.freepascal.org/view.php?id=12758

Sorry to bother Daruis (and everyone else) again, but this patch is holding my further work on TAChart.

Such are the problems of using centralized version control ;-)

+1

I have similar problems recently, when i had to wait a feature patch to be applied before i could fix a critical bug.

Luiz

I really wonder how a DVCS would solve this or what would be different? You just apply it to your local working copy and you've it in your builds?

I really wonder how a DVCS would solve this or what would be different? You just apply it to your local working copy and you've it in your builds?

Yes. The most important difference in this case is that DVCS would preserve local history. This is similar to every developer having his own branch in SVN (or even arbitrary number of local branches), with merges being almost as trivial as SVN's commits.

I.e. my specific problem can be solved in SVN by creating a branch of TAChart component and giving me commit access to it, but then similar branch should be created for my patches to DBGrid, and yet another one for patches to SynEdit (both stalled for about a month now), etc.
Obviously, this is not a scalable solution for many developers ;-)

But isn't the problem that the patches don't get into the central repository?

Though I've write access to the fpc repository ;) I've also several local "branches" (actually plain copies of my fpc checkout) with some changes in it.

But if it's not feasible for you, you can still use git-svn, no?

BTW: An fpc/lazarus git repository would be really no fun: due to the flaky connection a git clone of a converted repository is from svn.freepascal.org basically not possible, at least not for me from germany.

Obviously, this is not a scalable solution for many developers ;-)

I forget to mention: how does a DVCS scale better in this regard for small and medium sized projects (<100 developers)? As long as you don't get rejected commits due to two commits by two people at the same time?

They will get there eventually. The key thing is that patches can be 'batched' for review/application and not spoon-fed one by one. Look at what is going -- a feature can be implemented as a series of 10 or even 100 patches -- imagine how much time it would take to submit and review each patch sequentially.

Though I've write access to the fpc repository ;) I've also several local "branches" (actually plain copies of my fpc checkout) with some changes in it.

But this is limited to one change per sub a "branch".

But if it's not feasible for you, you can still use git-svn, no?

I'd like to. Unfortunalely, I use Lazarus on Windows, and git still has some troubles here.

BTW: An fpc/lazarus git repository would be really no fun: due to the flaky connection a git clone of a converted repository is from svn.freepascal.org basically not possible, at least not for me from germany.

Sorry, I can not parse this sentence.

how does a DVCS scale better in this regard for small and medium sized projects (<100 developers)?

DVCS does not require any central administration to create branches for every developer/feature. It also does not require network connection for doing commits, which is important to some contries/regions where Internet is still not cheap or reliable enough.

This can be done with an svn branch as well? I'am rather sure the lazarus people give you write access to a branch if you ask. And this has a real advantage: if you just commit your changes to your local repository, the changes get lost if you "disappear" and nobody did pull them yet (this is also why we recommend to attach patches to "bug reports", they won't get lost this way), the patches are lost. If they are in a svn branch, they aren't lost.

Look at what is going -- a feature can be implemented as a series of 10 or even 100 patches -- imagine how much time it would take to submit and review each patch sequentially.

The point about kernel.org is that they have dedicated reviewers. If lazarus has dedicated reviewers/merger then this could be done as well. The actual merge command of a branch in svn is a non brainer as well.

For testing purposes, I converted the fpc repository to git. However, due to the slow and unreliable connection of our vc server to my place, I was not able to clone this repository to my broken svn checkout can be continued, a git clone apparently not.

It requires it. Or how would you create releases then? The features must go into this repository and if noone does so, the feature is pretty useless as well.

It also does not require network connection for doing commits, which is important to some contries/regions where Internet is still not cheap or reliable enough.

See above :)

Alexander Klenin wrote

>> and yet another one for patches to SynEdit (both stalled for about a month now), >> etc

I just saw this, and consequently found your patches on this mailing list too.

As for the SynEdit patches (is-link-able), If you can submit them to mantis, I will take them and had a quick, yet not complete thing I can already tell is the way you check if it is a number:
not (Lines[Y - 1][X1] in ['0'..'9']) and

It is incomplete. $ABCD is a number in hex. Best would be to introduce a IsNumber in the highlighter (pascal, and baseclass), and check there. This would also keep synedit itself more agnostic to pascal specifics (even so, codetools only work on pascal source)

IsNumber has to deal with "1.99e3 " being cut into 2 words, so 99e3 is a number. Not sure what to do with "1.e2", but imho it wouldn't hurt to ignore this and have "e2" linkable.

Also you may need to check the list again, against context sensitive keywords. A "procedure self;" seems to compile.

Best Regards
Martin

Note that I posted two patches, and apparently you only found the older one ;-)

My initial approach was not optimal, as you noted, but neither is the second one,
and my questions about the best route were not answered. So if you have time and expertise, please read the mail threads mentioned in the bug report
and provide me with insight ;-)

--- El jue 11-dic-08, Alexander Klenin escribi?:

[snip]

Sorry about the dbgrid one, btw, cracker classes are sometimes called "access" classes but in this case I think it really made justice to the name, have you tried that on fpc 2.2.2 and current 2.3.1?.

If it gets applied it has to be temporal and as such, we need a patch for fpc also and another taking in count the patched fpc (but that can wait of course), if the fpc patch doesn't make it, it's unlikely the crack will be commited.

Jesus Reyes A.

?Todo sobre Amor y Sexo!
La gu?a completa para tu vida en Mujer de Hoy.
http://mx.mujer.yahoo.com/

Jesus Reyes wrote

Sorry about the dbgrid one, btw, cracker classes are sometimes called "access" classes but in this case I think it really made justice to the name, have you tried that on fpc 2.2.2 and current 2.3.1?. If it gets applied it has to be temporal and as such, we need a patch for fpc also and another taking in count the patched fpc (but that can wait of course), if the fpc patch doesn't make it, it's unlikely the crack will be commited.

I did produce some patch, see my mail "FCL-DB: Extend TLookupList so it can be used as picklist source" in the fpc-devel list. However, it seems there are even fewer reviewers in FPC team than Lazarus team ;-)

At least I would like to replace replace 'private' with 'protected' in TLookupList definition --
this trivial change could be even applied to fixes branch, and then Lazarus code can be updated to
use 'access' instead of 'cracker'.

--- El jue 11-dic-08, Alexander Klenin escribi?:
[snip]

It would be very good that this is included in next fpc release, let hope they are looking at this and there is still time for it.

Jesus Reyes A.

?Todo sobre Amor y Sexo!
La gu?a completa para tu vida en Mujer de Hoy.
http://mx.mujer.yahoo.com/

Yes. But other developers (like me) may want their branches that will require some admin effort (create branch, give access rights) from the main developers tree. With DVCS you start your own branch without incommode nobody.

An real example:
- i'm the developer of the Sqlite component shipped with fpc.
- Previously i worked locally and send various fixes as a patch to the fpc team. They complained.
- Then i started to send each change separately. So i was developing a change and then sending a patch separately. But i have other things to improve/fix and i had to wait to apply before i start another feature or fix.
- my solution: i created a mirror in my svn repository ( http://code.google.com/p/luipack/source/browse/#svn/trunk/sqlite/dataset ) and i commit each change to my svn separately and then send the changes in order. The ugly part is that there's no way to create the patches directly
from my svn i have to copy the files of a revision (if fpc is sync with rev 5, i copy rev 6) from my repository to the fpc repository then create a patch and sent. Them i wait to apply. Them i can do the same for rev 7. Very ugly.

You can publish your branch in the net. There are several free services that do that.

Remember that are other DVCS than git. (git is bad because of your complex installation at windows)

Luiz

Luiz Americo Pereira Camara wrote

An real example: - i'm the developer of the Sqlite component shipped with fpc.

Then maybe the best for you is to ask about write access to the SqlLite subtree of fpc trunk?

Same for Alexander Klenin - if you need to update TAChart very often then ask about write access to svn/lazarus/trunk/components/tachart

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Same for Alexander Klenin - if you need to update TAChart very often then ask about write access to svn/lazarus/trunk/components/tachart

Yes, it can be a workaround for my particular case, so whom should I ask?

In general, though, patch review is a good thing too -- e.g., while applying my latest patch to TAChart, Darius made a compatibility fix, which could be missed if the code went straight to trunk.

Jesus Reyes wrote

If it gets applied it has to be temporal and as such, we need a patch for fpc also and another taking in count the patched fpc (but that can wait of course), if the fpc patch doesn't make it, it's unlikely the crack will be commited.

Of course, see http://bugs.freepascal.org/view.php?id=12787 I did not produce the patch since it is trivial and will likely become outdated when the time will come to apply it.

Why would it become outdated? Reviewing and commtting an IFDEF should not take too long, if you have tested both 2.2.2 and 2.3.1.

Vincent

For FPC ask me ;)

I would love to contribute to FPC, but it is much harder to create (non-trivial) contribution then to Lazarus, and I simply do not have enough time.

Meanwhile, you can review my trivial contribution here ;-) http://bugs.freepascal.org/view.php?id=12566

Op vrijdag 12-12-2008 om 18:54 uur [tijdzone +1000], schreef Alexander Klenin:

There are many, many bugs in fpc which can be solved by trivial patches like this one. So there's enough to do. ;)

Joost.

It would be helpful having svn write access to fpc sqlite directory. Is there any specific rules?

Luiz

Of fcl-db? Ask Joost if it's ok then I'll add you.

Op zondag 14-12-2008 om 10:18 uur [tijdzone +0100], schreef Florian Klaempfl:

That's ok.

Joost.

Thanks. What should i do?

Luiz
-------------------------------------------------------------------------------- Na Oi Internet voc? ganha ou ganha. Al?m de acesso gr?tis com qualidade, voc? pode ter contas ilimitadas de email com 1 giga cada uma, suporte gr?tis e muito mais. Baixe gr?tis o Discador Oi em http://www.oi.com.br/discador e comece a ganhar.

Agora, se o seu neg?cio ? voar alto na internet,
assine Oi Internet Banda Larga e ganhe o modem gr?tis. Clique em http://www.oi.com.br/bandalarga e aproveite essa moleza!