Hi, I share J. approach on this. Unversioned files, *when* used inside a repo, containing relative paths should provide more automatization, for example, when making some sync or cloning. Of course, you may not want to sync each unversioned file each time (for example when large PDFs are unversioned files in the repository), but having to add them, *each time* before making any sync seems counter intuitive. `fossil uv sync -v` should, in some setting, allow such automatic behavior without previous `fossil uv add path/to/the-same-file` each time we want to resync unversioned files already in the repo.
Cheers, Offray On 26/06/18 11:48, j. van den hoff wrote: > On Tue, 26 Jun 2018 18:33:22 +0200, Stephan Beal > <sgb...@googlemail.com> wrote: > >> On Tue, Jun 26, 2018 at 5:45 PM <sky5w...@gmail.com> wrote: >> >>> Can unversioned files respect their original paths when added? >>> I have several locations for bitmaps, icons, pdf's, etc. >>> They do not necessarily reside in an isolated folder. > > yes, same here, *but* in directories *within* the checkout dir. > >>> >> >> That wouldn't work cross-platform. You might store file the C:\D\e\f.txt >> >> which i could not extract on Unix because we don't have drive >> letters. If >> we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless >> i was >> the root user. Case sensitivity is another problem in that regard. If >> you >> store C:\D\e.txt and C:\d\e.txt, those would map to two different >> folders >> on Unix systems. >> >> Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive >> should it use?). > > I was only thinking about *relative* pathnames w.r.t. checkout root > and that sure could be managed with the same logic cross-plattform as > versioned files, right? > > but as explained, I have not used uv-files until today (and have not > followed the discussion closely, when it was implemented). so I do not > know all the use cases that are of relevance here. > > I now -- in view of your mail -- understand of course that there could > be use cases (possibly the majority) where uv-files are located > somewhere else in the file tree, rather than in the checkout. no idea > how these should be properly handled, than. probably the way DRH just > proposed would than be the only way. > > o.t.o.h.: the special case, where *everything* (versioned and > unversioned files) reside together in the checkout dir might deserve > special consideration/handling. it seems to me the "logical" > extension/next step beyond "put everything under revision control": > still keep all the stuff that constitutes "the project" together in > one place (the checkout dir), but decide which files could be handled > as uv-files in order to safe on disk space/repo size. > > this would imply special handling of the case "`fossil uv ls'" reports > relative, rather than absolute pathnames" but maybe it could be quite > useful, just think of my simple example: a LaTeX doc including several > project-specific image files that I do not want to keep under revision > control but as part of the repo. the tex-file will no longer compile > on "the other side" if the uv-files are not put back into the expected > (relative) location... > >> > > _______________________________________________ fossil-users mailing list firstname.lastname@example.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users