Open GoogleCodeExporter opened 8 years ago
Hi Cameron,
somehow I can't get what the problem is. What do you mean by "have deleted the
working copy"? Do you mean source or destination?
What do you mean by "If there was an option to not sync delete"? FileSync
should not delete target files if source files were deleted?
This is be possible to implement, but then you will end up in the situation
where you have lot of garbage on the "remote" part. What you would do then?
My idea for FileSync is that it works as simple as possible, so that anyone can
understand the result. This means, the target folder should ideally be just a
mirror of the source. For all "sophisticated" workflows sophisticated tools
should be used, for example version control systems like git etc.
So while technically possible, I doubt I will implement it. You can try to
convince me. BTW a patch with attached junit tests would definitely help :-)
P.S.
The title of your report seems to be misleading: did you mean "Option to *not*
delete remote file on sync"?
Regards,
Andrey
Original comment by iloveeclipse
on 31 Aug 2014 at 9:08
I think he is saying that he has two developers. Developer A, and Developer B
both working on their own copy of a project (the local copy) in Eclipseand they
are both syncing to the same target folder.
If Developer A deletes /index.php and Developer B then syncs, Developer B's
setup will still have a local copy of /index.php and it will upload /index.php
as it is missing in the target folder (as the other developer just deleted it).
What Cameron seems to want is for this to be deleted in Developer B's local
Project too.
This is not what File Sync is designed for and it sounds like Cameron needs to
evaluate using Subversion (SVN) for version control. This is how the reset of
the world copes with multiple developers working on the same codebase.
Original comment by rs386...@gmail.com
on 16 Jul 2015 at 8:17
Original issue reported on code.google.com by
cameron....@gmail.com
on 27 Aug 2014 at 9:47