| # | User | Message | Date |
| 55 | Tomc | try svn cat and copy /pipe the result where you want | 22-Sep-09 22:03 |
| 54 | Maxim | using tortoise SVN, how can I checkout just a single file? here it complains about only wanting to checkout directories.... which is a bit dumb IMHO. note, this checkout occurs in a new checkout area, the directories on the repository aren't anywhere else. I just want to pick out one file from a repository and use just that elsewhere. | 21-Sep-09 18:59 |
| 53 | Thør | . | 2-Apr-06 9:55 |
| 52 | BrianH | FAT also stores file dates in 2-second increments, so file times can adjust up to two seconds when copied between FAT and NTFS. File times in ZIP files have the same restriction because of ZIP's DOS origins. | 5-Jan-06 3:22 |
| 51 | BrianH | They are with NTFS (which may be UTC internally), but are not adjusted with Fat (12/16/32) which stores files in local time. | 5-Jan-06 3:18 |
| 50 | Volker | Basically the filedates reported by windows are not adjusted to summertime. so after summertime-change the older files are one hour off. sometimes. depends on things like partition-types and dont know what else. | 4-Jan-06 21:34 |
| 49 | Pekr | it may be bug in Windows, but it needs to be sorted out. With Ladislav we even wrapped some Win32 funcs I found in rebol.exe, but watched nothing obvious ... | 4-Jan-06 21:20 |
| 48 | Pekr | http://www.rebol.net/cgi-bin/rambo.r?id=3822& | 4-Jan-06 21:19 |
| 47 | Pekr | the problems is reported in rambo ticket, will find it for you - it can report two zones +1 or + 2 here, and it is a problem - it depends if you skip the time the time is switched on, or if you go thru it ... | 4-Jan-06 21:18 |
| 46 | Graham | What is the problem with summertime ? When switching to daylight saving, the time zone changes. Eg ours goes from +12 to +13. | 4-Jan-06 21:17 |
| 45 | Volker | one problem is summertime and windows. | 4-Jan-06 20:57 |
| 44 | BrianH | By "for comparison purposes", I mean don't change the file date, just subtract the diff between you and UTC to get the adjusted file date in memory and then compare against the adjusted file date from the server. | 4-Jan-06 19:17 |
| 43 | BrianH | Better yet would be for both sides to adjust to UTC for comparison purposes. | 4-Jan-06 19:13 |
| 42 | BrianH | In theory, timestamp syncing can be done by asking the server for its current time or time zone, comparing against your own, and then adjusting your timestamps for comparison by the difference. I'm not sure how well this would handle latency issues (we should look at time protocols), but it would handle the client's computer clock being wrong. This would have to be done at the beginning of each syncing session, incase the client moves time zones or otherwise adjusts their clock between sessions. | 4-Jan-06 19:12 |
| 41 | JaimeVargas | Ok. | 4-Jan-06 14:49 |
| 40 | Pekr | back in mins ... | 4-Jan-06 14:49 |
| 39 | Pekr | well, if multilanguage, I am in and we can talk privately ... | 4-Jan-06 14:49 |
| 38 | JaimeVargas | BEER+FT is just the framework. Not an Application. For example you need to code the gui, path monitoring, filesets management, guid, plus others. | 4-Jan-06 14:48 |
| 37 | Pekr | If it works, I would LOVE to sell it to my own company I work for - to beat those Sap complex solutions :-) | 4-Jan-06 14:48 |
| 36 | Pekr | I might try to better earn some money, then finding free time and struggle implementing it myself. I could become CZ implementator, if I like the product :-) | 4-Jan-06 14:47 |
| 35 | Pekr | what scheme? We use PKCS7 certificates - qualified certificates .... | 4-Jan-06 14:46 |
| 34 | Pekr | Jaime - is that your commercial app? How different is it from your Beer plus FT profile? | 4-Jan-06 14:46 |
| 33 | JaimeVargas | e-signatures. No problem. What scheme. | 4-Jan-06 14:46 |
| 32 | Pekr | no, absolutly not ... the thing is, we need e-signatures, required by our law :-( ... maybe some command line util could be used? openssl? dunno :-( | 4-Jan-06 14:45 |
| 31 | JaimeVargas | But we be aware if you are looking for all of IOS functionality. We don't have that. | 4-Jan-06 14:44 |
| 30 | JaimeVargas | I see. They could test our tool immediately. | 4-Jan-06 14:43 |
| 29 | Pekr | I have got competition here though, guys try to write it in delphi - it looks ugly and sucks (they would take years to even aproach IOS level), yet they refused to even look into IOS, which would be better fit for our company right fromt he start ... | 4-Jan-06 14:42 |
| 28 | Pekr | yes, I might be, if I decide to go for the app ... I will post our company requirements in oportunities group, maybe today evening. Our company failed with big Sap system for file transfer. I wanted to create something upon which business could be based. I will not be selfish - I better publish what could be a good business imo, than doing nothing myself due to lack of free time or the lack of my coding knowledges ... | 4-Jan-06 14:41 |
| 27 | JaimeVargas | Everybody gets the same files. It is a comercial product. | 4-Jan-06 14:40 |
| 26 | JaimeVargas | Yes. Syncronization of files for multiple clients. | 4-Jan-06 14:39 |
| 25 | JaimeVargas | 2) You either implement locks or smart merging. | 4-Jan-06 14:39 |
| 24 | JaimeVargas | 1) Hashing is the only way. | 4-Jan-06 14:39 |
| 23 | Pekr | FT? | 4-Jan-06 14:39 |
| 22 | JaimeVargas | Are willing to license it? | 4-Jan-06 14:39 |
| 21 | JaimeVargas | We have 3) solved in BEER. | 4-Jan-06 14:38 |
| 20 | Pekr | I would like to have answered: 1) what technique to use for "timestamping" - do we continue with timestamps against one central time, or do we use hashes, or sequencing numbers, or mixture of mentioned techniqueues? We might look how others do it ... 2) better support for possible conflicts - imagine following scenario - you have some reblet, e.g. Contacts - one person starts editing it, then another person starts editing it too. First one syncs (saves changes), then second one does the same - changes of first ones are lost. How to aproach this - introduce some kind of resources locking? (not real locking, but we are message based, so could be queued) It could work as follows - person 1 wants to edit some record. Edit button posts request-for-lock. Lock is assigned. I other person tries to edit, it will not obtain lock. We could even introduce protocol level support, so that the person is informed, who has the lock, and how long. The trouble usually comes, when person goes off-line after the edit started - we need to remove dead-locks, so by default, I would lock for 20 minutes e.g. and the lock would have to be renewed, if person 1 wants to work longer with the given document ... another scenario is, when you actually start editing something which might require locking, but you start already being off-line. We could create lock-request, just not synced yet. Once you go on-line, you simply check seqno, if the lock is possible, and the given record not modified. But what if it was modified in the meantime? e.g. you might be working with stock system and someone else in the office sells few units, for which you may start writing offer for to another customer. Tough scenario - would like to know your opinion. Maybe some things simply need to be done on-line only? 3) I needed small file-sync scenario - could use IOS, but IOS can't sync and "forget". Simply idea is to have different kind of syncing techniques, so e.g. for file transfer you have dir to sync, if correctly synced, log it, forget it, delete it on client and or server (or not, it depends) as for IOS, local storage could be encrypted (or not), imported into RebDB (no single better solution so far introduced for rebol), sync-per-record or record-set could remain (record=document). RebDB on Serve would speed things up significantly too ... another possibility is to think outside the IOS terms, in more general way - simply thinking about world of objects, being in various states, with various life-time around internet and on-line or off-line devices. I think that maybe we could find some simpler solution than SyncML and the likes ... another point - such techniques should be transport independent, so I would not like to hear that it needs this or that ;-) So, anyone? | 4-Jan-06 14:35 |
| 19 | Pekr | Currently my intention is not to sync with various devices. It is simply kind of attempt to improve on IOS syncing, allowing sync-and-forget, or even not syncing (typical remote/server only access) and to improve/support off-line working reblets ... | 4-Jan-06 14:12 |
| 18 | Pekr | so - enough food for thought, gona read some papers/discussions now .... | 4-Jan-06 13:36 |
| 17 | Pekr | maybe wrong info - SyncML was maybe a bit proprietary, now it seems that oma is developing it as a standard .... | 4-Jan-06 13:36 |
| 16 | Pekr | Because there were some licensing issues with SyncML, it was taken over by http://www.openmobilealliance.org or so ... it seems to me that OMa DS and DM replace SyncML or so ... | 4-Jan-06 13:34 |
| 15 | Pekr | http://www.sync4j.org | 4-Jan-06 13:31 |
| 14 | Pekr | there also seems to be one standard - SyncML - http://www.syncml.org | 4-Jan-06 13:21 |
| 13 | Pekr | what is to be said the best file-sync for Mac - ChronoSync - http://www.econtechnologies.com | 4-Jan-06 13:15 |
| 12 | Pekr | one Czech product - http://www.mobiledit.com - quite popular, provides SDK etc. | 4-Jan-06 13:12 |
| 11 | Pekr | or even better - http://wiki.mozilla.org/Calendar:Home_Page , there is more syncing chapters .... | 4-Jan-06 13:08 |
| 10 | Pekr | http://wiki.mozilla.org/Calendar:Syncing_Algorithm | 4-Jan-06 12:33 |
| 9 | Pekr | http://www.opensync.org - synchronisation framework, although imo it solves higher level, e.g. connection to certain target apps via plug-ins etc. | 4-Jan-06 12:31 |
| 8 | Pekr | rsync - file syncing protocol - http://samba.anu.edu.au/rsync | 4-Jan-06 12:30 |
| 7 | Pekr | mine links are: | 4-Jan-06 12:29 |
| 6 | Pekr | I would like to post your opinion, links to various sync mechanism we could study, etc. IIRC Kaj talked about Groove techniques, so if it could be reposted, I would be glad ... | 4-Jan-06 12:29 |
| 5 | Pekr | - timestamp based syncing - that is another point - is it really a good idea? If it works, then it works, but not sure about its reliability .... | 4-Jan-06 12:28 |
| 4 | Pekr | - the problem of IOS syncing is, that it can't work in sync-and-forget mode - simply put, once you delete your file locally, there is no simple solution of how to tell server, that it is still ok | 4-Jan-06 12:26 |
| 3 | Pekr | - red-icons problem - untill particular rambo ticked is resolved, rebol's windows time-zone can't be in any way be regarded as being correct. and it does not depend if it is the bug of the OS, or rebol somehow ommits summertime adjusting flag of OS (if there is any under Windows) | 4-Jan-06 12:25 |
| 2 | Pekr | as for me personally, I first met with syncing with IOS, and I have to say, that I was hooked! It was really nice to watch, connecting even month later from my notebook, to sync properly what was missing .... However, later on, I found some limitation to such aproach. I don't want to talk about the speed - that could be corrected by using different technique for local storage, e.g. RebDB, but about following two problems: | 4-Jan-06 12:23 |
| 1 | Pekr | The objective of this group is to talk about various syncing techniques .... | 4-Jan-06 12:14 |